DMADV: Olmayan Bir Süreci Sıfırdan Tasarlamak

DMAIC bir süreci alır, ölçer ve düzeltir. Çalışması için ortada çalışan bir süreç olması gerekir.

Ama bazı işlerde öyle bir süreç yoktur. Yeni bir tesis açılıyordur, yeni bir iş birimi kuruluyordur, şirket ilk kez ERP'ye geçiyordur ya da mevcut düzen o kadar bozuktur ki iyileştirmek yerine yeniden kurmak daha kısa sürecektir. Bu durumlarda DMAIC boşa döner: ölçülecek bir taban yoktur, analiz edilecek bir kök neden yoktur.

DMADV, Altı Sigma'nın bu iş için kullandığı yoldur. Adı bazen DFSS — Design for Six Sigma olarak da geçer. Beş adımı vardır ve ilk üçü DMAIC ile aynı harfleri taşısa da içerikleri farklıdır.

Define     Measure     Analyze     Design      Verify
Tanımla →  Ölç      →  Analiz   →  Tasarla  →  Doğrula
                                                  │
                          canlıya alındıktan sonra │
                          DMAIC döngüsüne devredilir

Define — Tanımla

Neyin tasarlanacağını ve kimin için tasarlandığını yazarız. DMAIC'teki "problem cümlesi"nin yerini burada kapsam cümlesi alır: "Yeni açılan Gebze tesisinin sipariş–üretim–sevkiyat zinciri, mevcut ERP üzerinde kurulacak."

Bu adımda dört şeyi netleştiririz:

• Sınır. Hangi süreç zincirine dokunuyoruz, nerede bitiyoruz. Yeni tesisin muhasebesi kapsam içinde mi, değil mi?
• Paydaş. Kim kullanacak, kim onaylayacak, kim raporu okuyacak.
• Kısıt. Bütçe, tarih, mevcut sistemlerle uyum zorunluluğu, yasal gereklilikler.
• Başarı ne demek. Proje bittiğinde neye bakıp "oldu" diyeceğiz.

Son madde en çok atlanandır ve bir sonraki adımın tamamı ona dayanır.

Measure — Ölç

DMAIC'te bu adımda mevcut performansı ölçersiniz. DMADV'de ölçülecek bir performans yoktur; onun yerine beklentiyi ölçeriz.

Yöntem şudur: kullanıcıyla konuşulur (VOC — Voice of the Customer), söyledikleri ölçülebilir ölçütlere çevrilir (CTQ — Critical to Quality). Aradaki fark önemlidir:

Söylenen                        →  Ölçüte çevrilmiş hâli (CTQ)
"Sipariş teyidi hızlı olsun"    →  Teyit süresi ≤ 4 saat, siparişlerin %95'inde
"Stok tutsun"                   →  Sayım farkı ≤ %2, aylık
"Ay sonu erken kapansın"        →  Kapanış 5 iş gününde tamam
"Rapor beklemeyelim"            →  Dönemsel rapor ertesi sabah hazır

ERP tarafında bu adımın pratik faydası büyüktür. Çünkü CTQ listesi, ileride yapılacak tercihlerin hakemi olur: "bu alan zorunlu olsun mu?" sorusunun cevabı, o alanın hangi CTQ'yu beslediğine bakılarak verilir.

CTQ yazılmadan başlayan projelerde tercihler kişilere göre yapılır. Sonuç tanıdıktır: sistem çalışır, kimse itiraz edemez, ama kimse memnun da değildir.

Analyze — Analiz Et

Burada kök neden aranmaz; alternatifler üretilir ve karşılaştırılır. ERP dünyasında alternatif kümesi genellikle şu dörtten oluşur:

1. Standart modülü olduğu gibi kullanmak — en ucuz, en hızlı, en az esnek.
2. Standardı uyarlamak — orta maliyet, sürüm yükseltmelerinde bakım yükü.
3. Yanına özel uygulama koymak — ihtiyaca tam oturur, ERP çekirdeğine dokunmaz.
4. Başka bir sistemle entegre etmek — o iş için hazır bir sistem varsa mantıklı, veri akışının kurulması gerekir.

Alternatifleri CTQ'lara karşı tartarız. Basit bir tablo çoğu zaman yeter:

Tablonun amacı doğru cevabı vermek değil, tercihin neye göre yapıldığını kayda geçirmektir. Bir yıl sonra "bunu neden böyle yapmıştık?" sorusunun cevabı burada durur.

Design — Tasarla

Seçilen alternatif ayrıntıya iner. ERP projelerinde tasarım şu katmanlardan oluşur:

• Veri modeli ve ana veri. Ürün, müşteri, tedarikçi, masraf merkezi, birim kodları. Yeni kurulumların en çok zaman yiyen ve en çok hafife alınan parçası budur.
• Süreç akışı. Hangi belge hangi belgeyi doğuruyor, hangi durumda hangi adım atlanabiliyor.
• Yetki ve onay. Kim ne görecek, hangi tutarın üstünde kim onaylayacak.
• Ekranlar ve raporlar. Kullanıcının günlük işini yaptığı yer. Tasarımın kâğıt üstünde kalmaması buraya bağlıdır.

Bu adımda prototipi erken çıkarmayı tercih ediyoruz; tek bir bilinmeyen noktayı aydınlatmak gerektiğinde bunu süresi sınırlı bir spike olarak yapıyoruz. Ekranı toplantıda anlatmak yerine çalışır hâlde göstermek, tasarım hatalarının büyük bölümünü canlıya geçmeden ortaya çıkarır — erpware Builder ve TIVA Builder tarafındaki sürükle-bırak tasarım yaklaşımının asıl işi de budur.

Bir not: tasarımı tek seferde mükemmel kurmaya çalışmak, DMADV'nin en sık düştüğü tuzaktır. Tasarımın yeterince iyi olması ve Verify adımında ölçülebilir olması yeter.

Verify — Doğrula

Tasarımın Measure adımında yazılan CTQ'ları gerçekten karşıladığını kanıtlarız. "Test ettik, çalışıyor" bu adım değildir; çalıştığını ölçmek bu adımdır.

Sahada işleyen sıra şu:

1. Senaryo testi. Gerçek belgelerle, gerçek kullanıcılarla, uçtan uca. Ekran ekran değil, süreç boyunca.
2. Pilot. Tek bir depo, tek bir ürün grubu ya da tek bir tesis. Dar alanda çalışan tasarım, yayılmadan önce gerçek maliyetini gösterir.
3. Paralel çalışma. Kritik süreçlerde eski ve yeni bir süre birlikte yürür; iki sonucun farkı tasarımın açıklarını gösterir.
4. Canlı sonrası ölçüm. CTQ'lar ilk ay, üçüncü ay ve altıncı ayda yeniden ölçülür.

Son maddedeki ölçümü ErpwareBI üzerinde kalıcı bir gösterge hâline getiriyoruz. Böylece proje bittiğinde ölçüm de bitmiyor.

Ve burada devir teslim olur: yeni süreç canlıya alındıktan sonra iyileştirme sorumluluğu DMADV'den çıkar, DMAIC döngüsüne geçer. DMADV bir şeyi kurar; DMAIC onu yerinde tutar.

DMAIC mi, DMADV mi?

Son satır tartışmalı olanıdır. Kararı verirken sorduğumuz soru şudur: mevcut sürecin iskeleti doğru mu? İskelet doğruysa ve sorun uygulamadaysa DMAIC yeter. İskeletin kendisi yanlışsa — yanlış belge akışı, yanlış sorumluluk dağılımı, yanlış ana veri kurgusu — iyileştirme çabası yanlış yapıyı sağlamlaştırmaktan öteye gitmez.

Nerede tökezleniyor?

Üç kalıp tekrar ediyor:

1. Measure atlanır. CTQ yazılmadan tasarıma geçilir. Proje sonunda başarının ölçüsü "canlıya geçtik mi?" olur; kalite değil, takvim ölçülür.
2. Analyze tek alternatifle yapılır. İlk akla gelen çözüm tasarıma dönüşür. Alternatif üretilmediği için karşılaştırma da yapılamaz.
3. Verify canlıya geçişle karıştırılır. Sistem açılır, proje kapatılır, ölçüm hiç yapılmaz. Altı ay sonra "beklediğimiz gibi olmadı" denir ama neyi beklediğimiz yazılı değildir.

Üçünün ortak noktası şudur: hepsi projeyi kısa vadede hızlandırır, uzun vadede pahalıya patlar.

Biz nasıl yürütüyoruz

DMADV'yi ağır bir program olarak değil, yeni kurulan süreçlerde izlediğimiz sıra olarak kullanıyoruz. Define ve Measure adımlarını Süreç Danışmanlığı kapsamında, Analyze ve Design adımlarını ERP Proje Yöneticiliği çatısı altında yürütüyoruz. Gereken şey standartta olmayan bir ekran ya da akışsa özel uygulama geliştirme ve Entegrasyon Stüdyosu devreye giriyor; Verify adımının ölçümlerini ErpwareBI üzerinde kalıcı hâle getiriyoruz.

Yöntemin arka planı ve hangi parçasının ERP'de işe yaradığı için: Altı Sigma ve ERP.