“Benim işim acil”
Süreçlerinizde Little’s Law’un varsayımlarından birini her ihlal ettiğinizde, üretim bandınızın tahmin edilebilirliği üzerinde negatif etki yaratırsınız.
Bir hastane düşünün. Doktor sırasındasınız, sıradan bir muayane için geldiniz ve önünüzde bekleyen 3 hasta kalmış. Siz geleli 30 dakika olmuş, geldiğinizden bu yana 2 hasta girip çıkmış. Hızlı bir hesapla yaklaşık 45 dakikalık bekleme süreniz olduğunu tahmin ediyorsunuz. Her şey çok tahmin edilebilir…
Bir dakika.
Birden bir hareketlilik başlıyor, birisi tekerlekli sandalyeyle geliyor, durumu iyi değil. Hasta bakıcılar hızlıca doktorun yanına sokuyor. 10 dakikadır içerideler….
Sizin bekleme süreniz 55 dakika oldu.
Neyse.
Sıra artık işliyor, son 1 kişi kaldı.
O da nesi?
Ayakta zor duran yaşlı birisi geliyor. Onun adı sizden önce olunuyor, sizin önünüzden içeriye giriyor, 20 dakika kalıp çıkıyor.
Başta tahmin ettiğiniz 45 dakikalık bekleme süresi 10+20 dakika süren 2 kişinin araya girmesiyle 1 saat 15 dakikaya çıktı.
“Class of Service” ya da kısaltılmış şekliyle CoS, bazı işlerle diğerlerinden farklı şekilde ilgileneceğimizi anlatır. Genelde risk profiline bağlı olarak, bazı işler için tanımlı farklı politikalar uygulanabilir.
Doktor sırası örneğini hatırlarsak,
STANDART
ACİL HASTALAR
YAŞLILAR
şeklinde en az 3 tip CoS görüyoruz.
CoS kullanımının arkasındaki mantık, bazı işlerin çeşitli sebeplerle diğerlerinden ayrıcalıklı şekilde ilgilenilmesi gerekliliğidir. Örneğin, acil bir hastayı bekleyebilecek diğer hastalar varken sırada bekletmek çok büyük risk olabileceğinden ona öncelik tanınır. Bunun örneğini kuyruk olan pek çok yerde görürsünüz; havalimanlarında pasaport kontrollerde yaşlı ve çocuklular için yeni gişe açılır, bankalar farklı işler ve kart sahipleri için farklı bekleme süreleri tanımlar vb.
Daha önce de yazdığım gibi biz lTunes’da işleri Cost of Delay’e göre önceliklendiriyoruz. Ancak işlerin değer bazlı önceliklendirmesinin dışında çeşitli istisnâi durumlara göre önceden tanımlı bazı politikalarla “özel” bir şekilde ele alınması gereken durumlar olabiliyor. Regülasyonlar, kanuni zorunluluklar, OEM istekleri vb. işlerin standart akışının dışında ele alınmasını gerektirebiliyor.
Böyle durumlarda önceden tanımlı ve paydaşlarımızla paylaştığımız farklı CoS’larımız var:
STANDART
FIXED DATE
EXPEDITE
INTANGIBLE
TOP EXECUTIVES
Gerçek dünya örnekleriyle konuşursak, X tarihinde yayında olması gereken kanuni bir iş “FCFS, First Come First Served” şeklinde ilerlediğinde istenen sürede gerçekleşmeyebilir. Ya da sistemdeki anlık bir hata operasyonu durdurdu, diğer işlerin arkasına bunu atamayız. Bu örneklerde, tahmin edilen “lead” süresi, kanuni zorunluluğun geçerli olacağı tarihten ileride olacağı için diğer bir ya da birden fazla iş durdurulup ilgili işler araya alınmak zorunda kalınır.
Düşününce çok mantıklı geldi değil mi? Ama maalesef resmin tamamı bu değil, CoS sistemler için bazı durumlarda ne kadar bir gereklilik olsa da sistemin tahmin edilebilirliği üzerinde negatif bir etkisi vardır.
Bunu detaylı incelemek için de Amerika’lı bir matematik profesörünün kuramına bakalım.
Little’s Law
John Little 1928–1978 yılları arasında yaşamış Amerikalı bir MIT profesörü. Little 1961 yılında, adıyla anılan Little’s Law’un matematiksel olarak doğruluğunu ispat eder. Kuram, kuyruktaki istek sayısının “throughput” ve isteğin sistemde geçirdiği süreyle çarpımına eşit olduğunu söyler.
Yani;
Kuyruktaki iş sayısı = Çıktı adedi x İşin tamamlanma süresi
Bu kuramın güzelliği yalınlığında; bunu farklı varyasyonlara çevirerek tüm kuyruk kalıbına uyan sistemlerde uygulanabilir:
Çıktı adedi = Kuyruktaki iş sayısı / İşin tamamlanma süresi
İşin tamamlanma süresi = Kuyruktaki iş sayısı / Çıktı adedi
CoS’u Little’s Law’dan öğrendiklerimizle birleştirince CoS’un “lead” sürelerinin kısa olabilmesi için bazı WIP’in daha uzun süre beklemek durumunda kalacağı net olarak söylenebilir.
“It is not that you are predictable or are not predictable. It is that you “do” predictability. Predictability is proactive and not reactive. The actions you take today have the biggest impact on your predictability tomorrow.” — Daniel S. Vacanti
Doktor sırasını düşünürsek, acil hastalar ya da yaşlılar önünüze geçtiği için sırada normalden uzun süre beklersiniz. Süreçlerinizde Little’s Law’un varsayımlarından birini her ihlal ettiğinizde, üretim bandınızın tahmin edilebilirliği üzerinde negatif bir etki yaratırsınız.
Görünür olmasa da, takımların çoğunun işlerin tamamıyla aynı şekilde ilgilenmez, acil bir durumla ilgilenme şekliyle bir özellik geliştirdiğindeki yaklaşımı ya da altyapı güncellemesini ele alış şekli farklıdır. Ancak bunu tarifsiz ve insana bağlı şekilde yürüttüklerinde zorluklar yaşarlar.
Koçumuz Alper Gürbüz’ün yönlendirmesiyle lTunes’un 1. gününden itibaren kendi gerçekliğimizi tarifleyebilmek ve kontrol edebilmek için CoS kullanıyoruz.
CoS kullanırken şu konulara dikkat etmenin önemli olduğunu düşünüyorum;
- Gerçeklik neyse (işler standart dışı yollarla da geliyorsa) bunu politikalarla tarifleyin. (Örneğin, üst yönetim işlerini acil iş politikası ile işletirseniz hiç bir zaman board’a maliyetini göremezsiniz)
- Sürecin insan kararlarına bağımlılığını azaltın, politikalar konuşsun.
- Mümkün olduğunca işlerin standart gelmesini sağlayın, bunu ne derece iyi yaparsanız bandın tahmin edilebilirliği o düzeyde artar.
- Bunun paydaşlarla şeffaf ve açık şekilde paylaşın.
- Süreçle ilgili değişiklik yaparken, etkilerini ölçtüğümüzden emin olun. (WIP, lead süreleri, throughput, bekleme süresi gibi akış verilerini topladıktan sonra CFD, Control Chart ya da Lead Time Scatterplot ile etkileri izlemek ve ayarlamalar yapmak önemi, veri biriktikçe düzenli olarak süreç politikalarını ve etkilerini incelemenin değerli olduğunu düşünüyorum)
Özetle, board’unuzun hayatınızın gerçekliğini yansıtması önemli. Bunun için CoS kullanarak bunu açık şekilde göstermek gerekiyor. CoS kullanımının geliştirme bandının tahmin edilebilirliğine negatif etkide bulunduğunun farkında olarak sürekli ölçerek iyileştirme yapmak önemli.
