Bir iş sürecinin yavaş olduğu söylendiğinde teşhis neredeyse her zaman yürütme hızına gider: adım çok uzun sürüyor, öyleyse adımı hızlandıralım. Oysa şikâyet noktasına gelmiş süreçlerin çoğunda vakalar uçtan uca sürenin (lead time) büyük kısmını bekleyerek geçirir ve görevleri hızlandırmak toplam süreye neredeyse hiç yansımaz. Bu yazı Little Yasasını kesin biçimde ifade ediyor ve Kingman tipi değişkenlik akıl yürütmesiyle, kullanım oranı yaklaşık yüzde 80'i aştığında uçtan uca sürenin neden kararsızlaştığını gösteriyor. Ardından değişkenliği azaltmanın, el değiştirmeleri kaldırmanın ve devam eden işe limit koymanın, tuş vuruşlarından tasarruf etmekten çok daha fazla fark yarattığını savunuyor. Aynı aritmetikle bir uçtan uca süreyi dokunma ve bekleme bileşenlerine ayırabilir, beklemenin kullanım oranına ne kadar duyarlı olduğunu tahmin edebilirsiniz. Önerilen bir otomasyonun ölçülebilir bir şeyi değiştirip değiştirmeyeceği de önceden görülebilir.
Little Yasasının Kesin İfadesi
Little Yasası (Little, 1961), uzun bir aralık boyunca gözlenen bir kuyruk sisteminin üç niceliğini birbirine bağlar: sistemdeki ortalama iş sayısı, ortalama varış hızı ve bir işin sistemde geçirdiği ortalama süre.
L = λ · W
L = ortalama devam eden iş (sistemdeki iş sayısı)
λ = ortalama varış hızı (birim zamandaki iş sayısı)
W = iş başına sistemde geçen ortalama süre (uçtan uca süre)
Yasa bir korunum özdeşliğidir ve belirli bir kuyruğu modellemez. Varış ya da hizmet dağılımları, sunucu sayısı, kuyruk disiplini ve işlerin tek tek mi partiler hâlinde mi ele alındığı hakkında hiçbir varsayım yapmaz. İş süreçlerinde bunların hiçbiri bilinmez ve yasayı orada kullanılabilir kılan da bu genelliktir.
Yine de varsaydığı şeyleri bilmek gerekir, çünkü yanlış kullanımların çoğu bunları göz ardı etmekten doğar. Sistem, genel olarak durağan olduğu bir dönem boyunca gözlenmelidir: varış hızında bir eğilim olmamalı, kuyruk ne sınırsız büyümeli ne de tamamen boşalmalı. Sistemin sınırı tanımlı olmalı ve giren her iş sonunda çıkıp sayılmalıdır. Sessizce iptal edilen, başka bir iş akışına aktarılan ya da yeniden sınıflandırılan vakalar korunumu bozar. Üç nicelik de aynı aralık ve aynı popülasyon üzerinden alınmış ortalamalar olmalıdır.
Yeniden düzenlendiğinde yasa bir teşhis aracına dönüşür. W = L / λ, uçtan uca sürenin, işin çıkış hızına göre ne kadar işin devam ettiğine bağlı olduğunu söyler. Bu bir stok ifadesidir ve içinde çaba diye bir terim yoktur. Tamamlanma hızı sabitken açık vaka sayısı ikiye katlanırsa, kimse daha yavaş çalışmadığı hâlde her vakanın süresi de ikiye katlanır.
Dokunma Süresi ile Uçtan Uca Süre Ayrı Ölçümlerdir
Uçtan uca süre, bir vakanın tanımlı sınıra girdiği andan çıktığı ana kadar geçen süredir. Dokunma süresi (touch time, iş içeriği ya da işlem süresi de denir), birinin ya da bir şeyin o vakayı fiilen ilerlettiği aralıkların toplamıdır. İkisinin oranı akış verimliliğidir ve büro ile bilgi işinde çoğu zaman tek hanelidir.
Bu iki ölçüm farklı yollardan elde edilir ve süreç dokümantasyonu tam burada yanlışa sapar. Bir adımın ne kadar sürdüğünü sorduğunuzda insanlar dokunma süresini söyler, çünkü yaşadıkları kısım odur. Uçtan uca süre ise yalnızca durum geçişlerine düşülen zaman damgalarından çıkarılabilir. Bir vakanın bir adım için ne zaman hazır hâle geldiği ile üzerinde çalışmanın ne zaman başladığı ayrı ayrı işaretlenmelidir. Bu ayrım yapılmazsa kuyrukta bekleme süresi hizmet süresi olarak kaydedilir ve model yavaş çalışan biriyle uzun bir kuyruğu birbirinden ayıramaz. Bu geçişleri görüşmelerle toplamak yerine sistem olay kayıtlarından çıkarmak mümkün. Süreç madenciliğinin otomasyonun ön koşulu sayılması gerektiğini söylememizin nedeni de bu.
Bir koleksiyon kartı üreticisi için kurduğumuz otomatik kalite kontrol hattı bu farkı yakından gösteriyor. Yerine geçtiği manuel süreç sekiz saatlik bir geçiş olarak tarif ediliyordu ve bunun çok azı gerçekten denetimdi. Gerisi şunlardan oluşuyordu: gelen kutusunda bekleyen dosyalar, gözden geçirecek kişinin boşalmasını bekleyen bir tasarımcı, bir oturuma değecek kadar iş birikene kadar tutulan bir parti ve her biri diğerlerinin elindeki bilgiye ihtiyaç duyan üç kişi arasında gidip gelen tek bir üretim. Otomatik sürüm 90'dan fazla doğrulama kontrol noktası çalıştırıyor ve yaklaşık 15 dakikada bitiyor. Sürecin yaklaşık yüzde 95'i otomatik. Kazancın büyük kısmı kontroller arasındaki beklemelerin ve el değiştirmelerin kalkmasından geliyor, kontrollerin hızlanmasının payı çok daha küçük. Kontrol noktalarının nasıl tasarlandığı ayrı bir konu ve otomatik kalite kontrolün insan denetiminin yakalayamadığı neleri yakaladığı başlıklı yazıda anlatılıyor.
Kullanım Oranı Uçurumu: Yüzde 80 Yükün Üzerinde Kuyruk Süresi Neden Patlar
Beklemenin baskın olmasının nedeni, kuyrukta geçen sürenin yükle doğrusal artmamasıdır. Yoğun trafikteki tek sunuculu bir kuyruk için Kingman yaklaşımı (Kingman, 1961), hizmetten önceki beklenen bekleme süresini şöyle verir:
Wq ≈ ( ρ / (1 − ρ) ) · ( (ca² + cs²) / 2 ) · τ
ρ = kullanım oranı (varış hızı ÷ hizmet kapasitesi)
ca = varışlar arası sürelerin değişim katsayısı
cs = hizmet sürelerinin değişim katsayısı
τ = ortalama hizmet süresi (dokunma süresi)
Ortadaki çarpan değişkenliği, sondaki iş içeriğini temsil eder. Uçtan uca süreleri en çok ilk çarpan bozar, çünkü kullanım oranı bire yaklaştıkça ρ / (1 − ρ) sınırsız büyür. Değişkenlik ve dokunma süresi sabit tutulduğunda bu çarpan şöyle davranır.
| Kullanım oranı ρ | Kuyruk çarpanı ρ / (1 − ρ) | Yüzde 50 yüke göre bekleme |
|---|---|---|
| 0,50 | 1,0 | 1× |
| 0,70 | 2,3 | 2,3× |
| 0,80 | 4,0 | 4× |
| 0,90 | 9,0 | 9× |
| 0,95 | 19,0 | 19× |
| 0,98 | 49,0 | 49× |
Yüzde 50 ile yüzde 80 yük arasında bekleme dört katına çıkar, yüzde 80 ile yüzde 95 arasında ise neredeyse beş kat daha artar. Her kaynağı meşgul tutmanın akışı bozduğu iddiasının arkasındaki sayılar bunlar. Bir gözden geçirme ekibini yüzde 95 kullanım oranına göre kadrolayan bir kurum, bilançoda zaten hiç görünmeyen boş zamandan kurtulmak için on dokuz kat bekleme cezasını kabul etmiş olur. Reinertsen (2009) bu ödünleşimi ürün geliştirme yönetimindeki temel ekonomik hata olarak ele alır. Ohno'nun (1988) hattı dolu tutmak yerine durdurma konusundaki ısrarı da aynı fikrin atölyedeki karşılığıdır. Uçurumun üstünde her istasyonu meşgul tutmak, bütün sistemin çıktısının aleyhine işler.
Bu yüzden kullanım oranı gösterge panosu için zayıf bir ölçüttür. Gecikmeli gelir, doğrusal değildir ve bir çubuk grafikte yüzde 82'deki bir adım yüzde 94'teki bir adıma çok benzer, ama ikisi bambaşka davranır. Kuyruk uzunluğu ve kuyruktaki en eski işin yaşı ise uçuruma varılmadan önce hareketlenir.
Bekleme Süresinin Gizli Sürükleyicileri Olarak Varış ve Hizmet Değişkenliği
Kingman formülünün ortadaki çarpanı, kurumların çoğunun hiç ölçmediği çarpandır ve bekleme süresinin tamamını ölçekler. Varış ve hizmet değişkenliğini değişim katsayısı cinsinden yarıya indirmek, kullanım oranı ve dokunma süresi aynı kalırken beklemeyi kabaca dörtte birine düşürür. Bunun için kimsenin daha hızlı çalışması gerekmez.
Varış değişkenliği
Varış değişkenliğini kurumlar büyük ölçüde kendileri yaratır. Yukarı akıştaki partileme, ay sonu döngüleri, işi dalgalar hâlinde gönderen kampanyalar ve kuyruğu yeniden sıralayan öncelik müdahaleleri, varışların değişim katsayısını yükseltir. Deming'in (1986) genel nedenli ve özel nedenli değişkenlik ayrımı burada doğrudan geçerlidir. Geciken vakaları tek tek öne alıp hızlandırmak değişkenliği artırır. Artan değişkenlik ortalama uçtan uca süreyi yükseltir ve daha çok geciken vaka üretir. İşe yarayan, işin sisteme girişini düzleştirmektir, böylece iş eşit bir hızla gelir.
Hizmet değişkenliği
Hizmet değişkenliğinin üç kaynağı vardır: tek ve ayrıştırılmamış bir kuyruğu paylaşan karışık vaka tipleri, bir vakanın bırakılıp sonra yeniden ele alınmasına yol açan eksik girdiler ve yeniden işleme döngüleri. Ortalamanın on katı süren seyrek bir vaka sınıfı varyans terimine tek başına hâkim olabilir ve bu vakaları kısaltmaya çalışmak yerine ayrı bir akışa almak genellikle daha ucuzdur. Bu, dağıtık sistemlerdeki kuyruk gecikmesi (tail latency) mantığının operasyondaki karşılığıdır. Kleppmann (2017), kullanıcının gördüğü davranışı ortalamalardan çok yüksek yüzdeliklerin belirlediğini gösterir. Nielsen'in (1993) yanıt süresi sınırları (doğrudan manipülasyon için yaklaşık 0,1 saniye, kesintisiz düşünce için 1 saniye, dikkati tutmak için 10 saniye) insan adımları için de geçerlidir. Orada da insanların hissettiği şey, ortalamadan çok dağılımın kuyruğudur.
Kuyruğa Bağlı Bir Süreçte Otomasyon Gerçekten Nerede İşe Yarar
Uçtan uca süreye bekleme hâkimse ve beklemeye de kullanım oranı ile değişkenlik hâkimse, τ'yu otomatikleştirmenin değeri sınırlıdır. Dokunma süresini kısaltmak kullanım oranını düşürür ve uçurumun kenarındaki bir süreçte bunun faydası olur. Ama yüzde 60 kullanım oranı ve yüzde 4 akış verimliliğiyle çalışan bir süreç düşünün. Orada yalnızca daha hızlı veri girişiyle gerekçelendirilen bir girişim, kimsenin fark edeceği neredeyse hiçbir şey getirmez. Tasarruf edilen saatlere dayanan iş gerekçelerinin getiriyi olduğundan büyük göstermesinin bir nedeni bu. Konuyu belirsizlik altında otomasyon getirilerinin modellenmesi yazısında ayrıca ele aldım.
Kuyruğa bağlı bir süreçte otomasyon getirisini üç mekanizmayla kazanır. Bunları en değerliden başlayarak sıralıyorum. İlki el değiştirmeleri kaldırmaktır. Kişiler ya da sistemler arasındaki her aktarım bir kuyruk yaratır, bu yüzden bir el değiştirmeyi kaldırınca bütün bir bekleme aşaması da kalkar. İkincisi parti büyüklüğünü küçültmek. Partileme hem devam eden işi hem de varış değişkenliğini üretmenin en ucuz yoludur ve yazılımın parti yapmak için ekonomik bir nedeni yoktur. Üçüncü mekanizma değişkenliğin azalmasıdır: belirlenimci bir otomatik adımın hizmet değişim katsayısı sıfıra yakındır ve bu, ondan sonra gelen her şey için değişkenlik çarpanını küçültür.
Bir kart baskı şirketi için kurduğumuz RPA (robotik süreç otomasyonu) iş akışı ikinci mekanizmanın açık bir örneği. ERP sisteminden sipariş verisini çekiyor, sevkiyat etiketlerini biçimlendiriyor ve sipariş karşılamaya aktarıyor. Günde 800'den fazla kez çalışıyor. Etiketi insandan hızlı biçimlendirmesinin payı küçük, etkinin çoğu ekonomik parti büyüklüğünün bire inmesinden geliyor. Artık kimse etiketleri, bir çalıştırma birinin öğleden sonrasına değecek kadar birikene dek bekletmiyor. O kuyruk hiç oluşmuyor ve iş sipariş karşılamaya topaklar hâlinde gelmek yerine düzenli bir hızla geliyor.
En Ucuz Uçtan Uca Süre Müdahalesi Olarak Devam Eden İş Limitleri
Little Yasası en ucuz kaldıracı da gösterir. Mühendislik gerektirmeden, bir politika kararıyla çekilebilen tek kaldıraç budur. W = L / λ ise ve λ'yı talep belirliyorsa, L'ye üst sınır koymak doğrudan W'ye üst sınır koyar. Devam eden iş limiti bir yönetim kararıdır. Bir öğleden sonrada uygulanabilir ve ne yazılım ne de ek kadro ister.
Limitin ikinci derece etkileri aritmetiğin ötesine geçer. Bağlayıcı bir limit kısıtı görünür kılar, çünkü iş kısıtın önünde birikmeyi bırakır ve giriş noktasında geri çevrilmeye başlar. Goldratt'ın (1984) kısıtlar teorisi bir darboğazı ayrı bir çalışma yapmadan böyle bulur. Limit ayrıca dolu bir kuyruğun görünmeyen maliyetini, boş oturan bir kişinin herkesin gördüğü rahatsızlığına çevirir. Uygulamada üst sınırı bugünkü ortalama devam eden iş düzeyine yakın koyun, adım adım düşürün ve kuyruklar kısalmayı bıraktığında ya da kısıt işsiz kalmaya başladığında durun.
Örnek Bir Hesaplama: Bir Onay Sürecinin Teşhisi
Aşağıdaki sayılar gerçek bir projeden alınmadı, aritmetiği göstermek için kurgulandı. Varsayımları açıkça yazıyorum ki yerine kendi sayılarınızı koyabilesiniz.
Altı sıralı adımdan oluşan, günde 20 vakanın geldiği ve herhangi bir anda ortalama 60 açık vakanın ölçüldüğü bir onay süreci düşünün. Little Yasası W = 60 / 20 = 3 iş günü verir. Bildirilen dokunma sürelerinin toplamı 55 dakika olsun. Akış verimliliği bu durumda üç adet sekiz saatlik güne karşı 55 dakika, yani yaklaşık yüzde 3,8 olur.
İki müdahaleyi karşılaştıralım. En büyük iki adımı otomatikleştirip toplam dokunma süresinin yarısını kaldırmak, 1.440 dakikalık uçtan uca süreden kabaca 27 dakika siler. Bu yaklaşık yüzde 1,9 eder ve haftadan haftaya oynayan sayıların arasında kimse fark etmez. Devam eden işi 30 vakayla sınırlamak ise tamamlanma hızı değişmediği sürece W = 30 / 20 = 1,5 gün verir. Bu, geliştirme maliyeti olmayan bir politika değişikliğiyle gelen yüzde 50'lik bir azalma. Bir de üçüncü seçenek var. Dördüncü adım 0,93 kullanım oranıyla çalışıyorsa, ölçülü bir kapasite kaydırmasıyla onu 0,80'e indirmek kuyruk çarpanını yaklaşık 13'ten 4'e düşürür. Bu etki genellikle diğer ikisinin toplamından büyüktür.
Karar kuralı mekaniktir. Önce akış verimliliğini ölçün. Kabaca yüzde 15'in altındaysa süreç kuyruğa bağlıdır. Bu durumda dokunma süresi otomasyonunu tasarruf edilen saatlerle gerekçelendirmeyin, gerekçe el değiştirmelerin ya da parti büyüklüğünün azalması olmalı. Yüzde 40'ın üzerindeyse iş içeriği gerçekten baskındır ve görev düzeyinde otomasyon doğru hedeftir. Aradaki bölgede adım başına kullanım oranını ölçün ve kod yazmadan önce 0,85'in üzerindeki her adımı düzeltin.
Sınırlamalar
Bu analiz bir yapı ortaya koyuyor, tahmin yapmıyor. Little Yasası, sınır ve durağanlık koşullarının sağlandığı her yerde geçerlidir. Kingman'ın ifadesi ise en iyi yoğun trafiğe ve tek sunuculu kuyruklara uyan bir yaklaşımdır. Çok sunuculu adımlar, öncelik kuralları, bloklanma ve süreçler arasında paylaşılan çalışanlar bu yaklaşımdan bazen epey sapar. Tablo yalnızca kullanım oranı çarpanı üzerindeki aritmetiktir ve gerçek bir sürecin bekleme süresi hakkında bir şey öngörmez. İşlenmiş örnek de kurgudur ve bütün varsayımları yazılıdır. Birinci elden verdiğimiz sayılar kendi projelerimizden geliyor ve o projelerin koşullarına özgü. Sekiz saatten on beş dakikaya inişi esas olarak beklemelerin ve el değiştirmelerin kalkmasına bağlamamız, o proje hakkındaki mühendislik yargımızdır. Bunu kontrollü bir ölçümle doğrulamadık. Dokunma süresini azaltmanın elbette bir faydası var, ama bu fayda akış verimliliğiyle sınırlı. Sürecin akış verimliliğini ölçmemiş bir proje ekibi, beklenen getiriyi de hesaplayamaz.
Kaynaklar
- Deming, W. E. (1986). Out of the Crisis.
- Goldratt, E. M. (1984). The Goal.
- Kingman, J. F. C. (1961). The Single Server Queue in Heavy Traffic.
- Kleppmann, M. (2017). Designing Data-Intensive Applications.
- Little, J. D. C. (1961). A Proof for the Queuing Formula: L = λW.
- Nielsen, J. (1993). Usability Engineering.
- Ohno, T. (1988). Toyota Production System.
- Reinertsen, D. G. (2009). The Principles of Product Development Flow.