Operasyonel Mükemmellik Sahada Başlar, Sistemde Kalıcı Olur

Operasyonel mükemmellik üzerine yazılanların çoğunda tanım aynı: süreçleri sürekli iyileştirerek israfı azaltmak, müşteri için değeri artırmak. Tanımda anlaşmazlık yok. Sahada tıkandığı yer başka: iyileştirme yapılıyor, altı ay sonra süreç eski hâline dönüyor. Bunun sebebi çoğu zaman yöntem değil — iyileştirmenin sistemde karşılığının olmaması.

Yalın Enstitü'nün operasyonel mükemmellik rehberi konuyu doğru yerden kuruyor: liderliğin sahiplenmesi, süreçlerin haritalanması, çalışanın problem çözmeye yetkilendirilmesi, doğru göstergelerin izlenmesi ve bütün bunların kültüre dönüşmesi. Katılıyorum, ekleyecek bir itirazım yok. Benim eklemek istediğim şey, ERP ve üretim sahasından gelen bir tamamlayıcı: bu dönüşümün kalıcı olup olmayacağını büyük ölçüde insanların her gün açtığı ekran belirliyor.

Küçük bir not: büyük harfle OPEX (Operational Excellence) operasyonel mükemmelliktir; küçük harfle OpEx (operational expenditure) işletme giderleridir. Aynı toplantıda ikisi de konuşulabildiği için karışıyor. Doğru kurgulanmış bir OPEX çalışmasının OpEx'i düşürmesi beklenir; ama bunlar aynı şey değil.

Panolar neden asılıyor, sonra iniyor?

Sahada tanıdık bir döngü var. Güzel bir çalışma yapılır: değer akışı haritalanır, israflar görünür hale gelir, kaizen başlar, pano asılır. Altı ay sonra bakarsınız: pano güncel değildir, A3'ler klasörün içindedir, süreç sessizce eski hâline dönmüştür. Kimse kötü niyetli değildir, kimse yalın düşünceye karşı çıkmamıştır.

Shingo Institute'ün modelinde bunun iyi bir açıklaması var: amaç ve sistemler davranışı yönlendirir. Sistemler çoğunlukla belirli bir sonucu üretmek için tasarlanır, o sistemin insanlara hangi davranışı yaptırdığı hesaba katılmaz. Sonra da davranışın değişmesi beklenir.

Bir üretim işletmesinde davranışı en çok yönlendiren sistemlerin başında ERP gelir. Operatörün kaydı hangi ekrandan girdiği, planlamacının listeyi nereden aldığı, kalitecinin hurdayı hangi kodla yazdığı, ustabaşının vardiya devrini neye bakarak yaptığı — bunların hepsi davranıştır ve hepsi sistem tarafından şekillendirilir. İyileştirme bu ekranlara hiç dokunmuyorsa, onu ayakta tutan tek şey insanların iyi niyeti olur. Vardiya değişir, iyi niyet biter.

Sahada gördüğüm beş kopma noktası

1. Ölçüm Excel'de yaşıyor. OEE, ilk seferde doğru oranı, duruş süreleri elle doldurulan formlardan toplanıyor; birisi hafta sonu oturup tabloyu hazırlıyor. Kişiye bağımlı, gecikmeli ve her toplantıda "bu rakam doğru mu" tartışmasıyla başlayan bir ölçüm, iyileştirmeyi taşıyamaz.

2. Standart iş ekranda karşılık bulmuyor. Yeni standart belirlenir, talimat asılır, ama sistem hâlâ eski yolu mümkün kılar — hatta kolaylaştırır. İnsanlar bu durumda sistemin dışında çalışmaya başlar. Gölge süreçler böyle doğar: sistemde bir kayıt, gerçekte başka bir akış.

3. İyileştirme kurala dönüşmüyor. "Bundan sonra şu kontrolü yapacağız" kararı bir alan, bir zorunluluk ya da bir uyarı hâline gelmiyorsa, o karar bir kişinin hafızasında yaşıyor demektir. O kişi izne çıktığında iyileştirme de izne çıkar.

4. İyileştirmenin ölçüsü olan veri zaten hatalı. Duruşların yarısı "diğer" koduyla kapanıyor, hurda nedenleri tek bir kodda toplanıyor, sistemdeki temin süresi yıllardır güncellenmemiş. Bu veriyle yapılan analiz, kök nedeni değil kod alışkanlığını ölçer. Kaizen'den önce yapılacak iş, ölçüyü düzeltmektir.

5. Görünürlük gecikiyor. Sorun perşembe günü oluyor, pano pazartesi güncelleniyor, toplantı çarşamba yapılıyor. Yalının "sapmayı anında gör" ilkesiyle haftalık raporlama aynı cümlede duramaz.

Önce yalınlaştır mı, önce dijitalleştir mi?

Bill Gates'in bilinen kuralı bu tartışmanın yarısını çözüyor: verimli bir operasyona uygulanan otomasyon verimliliği büyütür, verimsiz bir operasyona uygulanan otomasyon verimsizliği büyütür. Doğru. Kötü bir süreci dijitalleştirirseniz elinizde hızlı ve pahalı bir kötü süreç kalır.

Ama aynı cümleden yanlış bir sonuç da çıkarılıyor: "Biz önce yalınlaşalım, sisteme sonra dokunuruz." Pratikte o "sonra" hiç gelmiyor. Çünkü sürekli iyileştirmenin tanımı gereği bir bitiş çizgisi yok; sistemi bekletirseniz sonsuza kadar beklersiniz. Ters tuzak da var: "Önce ERP'yi kuralım, yalınlaşmayı sonra yaparız." O zaman da mevcut karmaşa sisteme gömülür ve sökülmesi çok daha pahalı hale gelir.

İşleyen orta yol, sırayı büyük bir programa değil küçük bir döngüye bağlamak:

1. Sahada iyileştirin. Bir adımı, bir onayı, bir taşımayı kaldırın. Henüz yazılım yok.
2. Yeni hâlin ölçümünü sisteme koyun. Elle doldurulan formu değil, sistemde kendiliğinden oluşan kaydı ölçün.
3. Standardı ekrana gömün. Yeni kural bir alan, bir zorunluluk, bir uyarı ya da bir onay akışı olsun.
4. Bir sonraki konuya geçin. Tek hücre, tek malzeme grubu, tek süreç. Fabrikanın tamamı değil.

Bu döngünün üçüncü adımı atlandığında dördüncüye geçilemiyor; çünkü ilk iyileştirme ayakta kalmadığı için ekip ikincisine inanmıyor.

Ne ölçmeli?

Yalın tarafın klasik göstergeleri sağlam: ilk seferde doğru oranı, teslim süresi, birim maliyet, müşteri şikâyeti ve tavsiye skoru, hayata geçen öneri sayısı, OEE. Buna sahadan üç ölçü daha eklerim:

• Veri kalitesinin kendisi. "Diğer" koduyla kapanan duruşların yüzdesi, sistemdeki temin süresiyle gerçekleşen arasındaki sapma, kapatılmamış açık siparişlerin sayısı. İyileştirme başlamadan önce düşmesi gereken sayılar bunlar.
• Önerinin kapanma süresi. Öneri sayısı katılımı gösterir, kapanma süresi güveni gösterir. Cevapsız kalan öneri, bir sonrakini engeller.
• Excel testi. Planlamacı ya da ustabaşı, sistemde zaten var olan veriyi Excel'e yeniden giriyor mu? Giriyorsa sistem o işi taşımıyor demektir. (Senaryo denemek için Excel açmak başka şeydir; veriyi yeniden yazmak başka.)

Bir de uyarı: maliyet göstergesini her zaman bir servis göstergesiyle birlikte izleyin. Stok devir hızını tek başına kovalayan bir çalışma, müşteri teslimini bozarak "başarılı" görünebilir.

KOBİ'de mümkün mü?

Mümkün, hatta çoğu zaman daha hızlı sonuç verir: karar yolu kısadır, aradaki kademe azdır. Ama engel kaynak değil zaman. Günlük işten kimse kopamıyor; üç aylık bir program takvime konuyor, ikinci haftada iş araya giriyor.

Bu yüzden küçük işletmede operasyonel mükemmelliği haftada iki saatlik tek bir konuyla başlatmak, kapsamlı bir dönüşüm programı kurmaktan daha gerçekçi. Tek bir hücrede, tek bir üründe, tek bir raporda sonuç alındığında devamı kendiliğinden geliyor.

Ofisteki israf: mükerrer giriş ve bekleyen onay

Üretimdeki israf gözle görülür: bekleyen palet, fazla stok, geri dönen parça. Ofisteki israf görünmez. Aynı verinin iki sisteme elle girilmesi, imza bekleyen form, e-posta ekinde dolaşan Excel, "acaba onaylandı mı" diye atılan mesaj.

Buradaki iyileştirme aracı çoğu zaman yeni bir yazılım değil: var olan sistemin doğru kurulması, iki sistemin birbiriyle konuşturulması ve gereksiz onay adımının tamamen kaldırılmasıdır. Sırayı karıştırmamak gerekiyor — kaldırılmayan bir adımı yazılımla hızlandırmak, o adımı kalıcı hale getirir.

Son söz

Yazılım tek başına ne yalınlaştırır ne bozar; mevcut süreci hızlandırır. Hangi yöne hızlandığına süreci tasarlayan karar verir. Operasyonel mükemmellik de bu yüzden bir yazılım projesi değil; ama ölçümü, standardı ve kuralı sistemde karşılık bulmayan hiçbir iyileştirme kalıcı olmuyor.

Kavramın tanımı, metodoloji listesi ve gösterge seti için Operasyonel Mükemmellik (OPEX) saha notuna bakabilirsiniz.

Bu ay yaptığınız son iyileştirme, sistemde bir alan, bir kural ya da bir rapor olarak karşılık buldu mu? Bulmadıysa o iyileştirme, büyük ihtimalle bir sonraki vardiya değişimine kadar dayanır.

Kaynaklar

1. Yalın Enstitü, Operasyonel Mükemmellik (OPEX) Nedir? Nasıl Elde Edilir? — tanım, metodolojiler, OPEX ile OpEx ayrımı ve gösterge listesi.
2. Shingo Institute, The Shingo Model — "Purpose and Systems Drive Behavior" içgörüsü.
3. Lean Enterprise Institute, What is Lean? — amaç, süreç ve insan sorularıyla kurulan yalın dönüşüm çerçevesi.
4. Bill Gates, Business @ the Speed of Thought, 1999 — verimli ve verimsiz operasyonda otomasyonun etkisine dair kural.