Yalın süreç iyileştirme: Veriye dayalı rehber

Yalın süreç iyileştirme, işlerin nerede zaman ve kalite kaybettiğini belirlemenize, ardından değişiklikleri verilerle sınamanıza yardımcı olan sistematik bir yaklaşımdır. Bu rehberde Yalın Six Sigma ve DMAIC’in iyileştirme çalışmalarına nasıl katkı sağladığını, her aşamada hangi verilere ihtiyaç duyulduğunu ve bu döngünün Siparişten Tahsilata sürecine nasıl uygulanacağını anlatıyoruz. Amaç, güvenilir bir başlangıç noktası oluşturmak, varsayımları analizlerle sınamak ve iyileştirmelerin kalıcı olmasını sağlayacak kontrolleri belirlemektir.

Yalın süreç iyileştirme, araçlardan oluşan bir koleksiyondan ibaret değildir. DMAIC, bir süreci incelemek ve neyi değiştireceğinize karar vermek için pratik bir yapı sunar.

Yalın Six Sigma nedir, ne değildir?

Yalın yaklaşım, Six Sigma ve Yalın Six Sigma birbiriyle ilişkilidir, ancak farklı sorunları ele alır.

Yalın yaklaşım, bekleme, gereksiz devir teslimler ve yeniden çalışma gibi değer katmayan işleri ortadan kaldırmayı hedefler. Six Sigma, değişkenliği ve kusurları azaltmaya odaklanır. Yalın Six Sigma, bu hedefleri yapılandırılmış bir iyileştirme çalışmasında birleştirir.

Değer akışı haritalama da dahil olmak üzere yalın süreç haritalama, işin nasıl ilerlemesi gerektiğini görselleştirmenize yardımcı olur. Süreç verileri, vakaların sistemlerde gerçekte nasıl ilerlediğini de gösterir. Harita ve veriler bir arada, sürecin beklentilerden nerede saptığını ekibinizle konuşmanız için bir temel oluşturur.

Yalın Altı Sigma’nın ne olmadığını da açıkça belirtmek gerekir:

• Bir sertifika programı değildir. Kuşaklar bir eğitim biçimidir. Bir sertifika, ölçülmüş bir başlangıç değerinin veya gerçek bir iyileştirme projesinin yerini tutmaz.
• Süreç bilgisinin yerini tutmaz. DMAIC incelemeyi yapılandırır, ancak ekibinizin işi ve işin kısıtlarını yine de anlaması gerekir.
• Tek seferlik bir proje değildir. Kontrol aşaması, proje ekibi çalışmayı tamamladıktan sonra süreci izlemenizi sağlar.
• Üretimle sınırlı değildir. Ofis süreçlerinde de bekleme, yeniden çalışma, devir teslim ve gereksiz adımlar bulunur.

DMAIC neden görüş değil, veri gerektirir?

DMAIC’te Ölçüm aşaması bulunur; çünkü bir sürecin iyileşip iyileşmediğini anlayabilmek için önce başlangıç değerini belirlemeniz gerekir. Bu değer yoksa Analiz aşaması, kimin hatırladığının doğru olduğu üzerine bir tartışmaya dönüşebilir.

Süreci anlamak için gözlem ve örnekleme yapabilirsiniz, ancak bunlar yalnızca gözlemlediğiniz vakaları ve adımları kapsar. Ofis süreçlerinde işler ERP, CRM, destek talebi sistemi ve elektronik tablolar arasında ilerleyebilir. Tek bir gözlemci, her vakayı başından sonuna kadar göremez.

Sistemler vaka referansını, etkinliği ve zaman damgasını kaydettiğinde, bu olay kayıtlarını kullanarak vakaların süreçte nasıl ilerlediğini yeniden oluşturabilirsiniz. Böylece her gözlemi tek tek toplamak yerine verileri kontrol edip sonuçları yorumlamaya odaklanırsınız. Process Mining, süreç genelindeki bu kayıtları incelemenin bir yolunu sunar.

Belgelenen işleyişle gerçekte yapılan işi karşılaştırmak, iki tür farkı ortaya çıkarabilir:

• Diyagramda yer alıp uygulamada görülmeyen adımlar. Bir kontrol artık yapılmıyor veya bir onay artık gerekmiyor olabilir.
• Uygulamada gerçekleşip diyagramda yer almayan adımlar. Bir geçici çözüm, sorumlusu veya incelemesi belirlenmeden rutin hâle gelmiş olabilir.

Yalın süreç iyileştirmede DMAIC’in beş aşaması

DMAIC’in beş standart aşaması vardır: Tanımla, Ölç, Analiz et, İyileştir ve Kontrol et. Her aşama farklı bir soruyu yanıtlar ve farklı bir çıktı üretir. Bu yalın süreç iyileştirme adımları, tanımlanmış bir sorundan izlenen bir değişime ilerlemenize yardımcı olur.

Tanımla: Sorunu, kapsamı ve CTQ’ları belirleyin

Verinin yerine geçtiği: hangi vakaların ve etkinliklerin kapsama girdiğine ilişkin varsayımlar.

Çözmek istediğiniz sorunu, sürecin sınırlarını ve müşteri ya da işletme açısından önemli kalite ölçütlerini (CTQ) tanımlayın. Önce neyin bir vaka sayılacağı konusunda anlaşın. Bu bir sipariş, destek talebi, fatura veya hasar talebi olabilir. Bu seçim, hangi olayları bir araya getireceğinizi belirler ve sonraki tüm ölçümleri etkiler.

Ekibin ilk değerlendirmesinin işlerin bugün nasıl yürüdüğüyle örtüşüp örtüşmediğini süreç verileriyle kontrol edin. Analiz, atölye çalışmasında gündeme gelmeyen farklılıkları veya ölçütleri ortaya çıkarabilir. Ekibin aynı görünüm üzerinden değerlendirme yapabilmesi için kapsamı bir süreç haritasında veya BPMN diyagramında belgeleyin.

Beklenen çıktı: bir ekibin sahiplenebileceği kapsam, herkesin anlayacağı vaka tanımı ve mevcut verilerle ölçebileceğiniz CTQ’lar.

Ölç: Çevrim süresi, maliyet ve yeniden çalışma için başlangıç değerini belirleyin

Verinin yerine geçtiği: mevcut performansı temsil etmesi beklenen tahminler ve küçük örneklemler.

Süreci, Tanımla aşamasında üzerinde anlaştığınız CTQ’lara göre ölçün. Mevcut verilere ve projenin kapsamına bağlı olarak başlangıç değeri, vaka başına çevrim süresini, maliyeti ve yeniden çalışmayı içerebilir.

Süreç birden fazla sisteme yayılıyorsa bu sistemlerin kayıtlarını nasıl ilişkilendireceğinizi kontrol edin. Üzerinde anlaşılan bir vaka kimliğiyle günlükleri birleştirmek, vakayı sistemler arasında izlemenize yardımcı olabilir. Sonuçlara güvenmeden önce birleştirme işlemini ve temel zaman damgalarını doğrulayın. Eksik veya hatalı bir birleştirme, başlangıç değerini olduğundan daha kesin gösterebilir.

Hedef belirlemeden önce mevcut performansı tanımlamak için başlangıç değerini kullanın. Ölçümleri, yalnızca kolayca çıkarılabildikleri için seçmek yerine sorun tanımına bağlı tutun.

Beklenen çıktı: süreç sorumlusunun inceleyebileceği, dayandığı varsayımları ve veri kısıtlarını da içeren bir başlangıç değeri.

Gerçek süreç verilerinden başlangıç ölçümünün nasıl oluşturulacağını görün.

Analiz et: Darboğazları, varyantları ve uygunluk farklarını bulun

Verinin yerine geçtiği: gerçek süreç davranışıyla karşılaştırılmamış atölye çalışması varsayımları.

Performansın neden değiştiğini anlamak için kanıtları inceleyin. Gecikmelerin nerede biriktiğine, hangi süreç varyantlarının görüldüğüne, daha az kullanılan yolların ne kadar hacim taşıdığına ve vakaların amaçlanan süreçten nerede ayrıldığına bakın.

Süreç varyantı, vakaların süreç boyunca izlediği yollardan biridir. Varyantları karşılaştırmak, gecikmenin yaygın mı olduğunu yoksa belirli bir yolda mı yoğunlaştığını görmenize yardımcı olur. Uygunluk analizi, gerçek davranışı amaçlanan süreçle karşılaştırarak ikisi arasındaki farkları belirlemenizi sağlar.

Olası nedenleri etkilerine göre sıralayın ve verilerle sınayın. Güçlü bir analiz, ekibin ilk varsayımını doğrulayabilir; ancak asıl kısıtın başka bir yerde olduğunu da gösterebilir. Uygulamalı bir anlatım için bir sürecin nasıl analiz edileceğini ve darboğazların nasıl bulunacağını inceleyin.

Beklenen çıktı: kanıtlarla desteklenen ve sorgulamaya açık, önceliklendirilmiş olası temel nedenler listesi.

İyileştir: Değişiklikleri uygulamaya almadan önce önceliklendirin ve test edin

Verinin yerine geçtiği: bir değişikliği tanıdık veya duyurması kolay olduğu için seçmek.

Bulduğunuz nedenleri ele alacak değişiklikleri belirlemek için analizden yararlanın. Beklenen etkiyi gereken çaba ve riskle karşılaştırın. Mümkün olduğunda hedef süreci modelleyin ve uygulamaya almadan önce senaryoları simüle edin. Böylece simülasyonun gerçekleşecekleri garanti ettiği izlenimini vermeden, değişikliğin süreci nasıl etkileyebileceğini inceleyebilirsiniz.

İşi yapan kişilerin yeni akışı anlayabilmesi için hedef süreci belgeleyin. Uygulama sonrasında başlangıç değeri için kullandığınız göstergeleri yeniden ölçün. Bu karşılaştırma, değişikliğin performansı iyileştirip iyileştirmediğini veya başka bir yerde yeni bir kısıt oluşturup oluşturmadığını değerlendirmenize yardımcı olur.

Beklenen çıktı: başlangıç değeriyle karşılaştırılarak test edilmiş ve uygulama sonrasında gerçek performansı kontrol etmek için bir planı olan değişiklik.

Kontrol et: Performansı, Dashboardları ve sorumluluğu izleyin

Verinin yerine geçtiği: performans değişikliklerini fark etmek için ara sıra yapılan denetimlere veya belleğe güvenmek.

Kontrol aşaması, iyileştirmenin sürdürülmesine yardımcı olur. İzleyeceğiniz ölçümleri seçin, inceleme gerektirecek eşikleri belirleyin ve yanıt vermekten sorumlu kişiyi atayın. Bir Dashboard, süreç sorumlusunun performansın değişip değişmediğini ve nerede inceleme yapması gerektiğini görmesine yardımcı olabilir.

Gözden geçirme sıklığı ve bir ölçüm beklenen aralığın dışına çıktığında atılacak adımlar konusunda anlaşın. Hacimler veya vaka bileşimi değiştikçe sürecin ve hedeflerinin hâlâ geçerli olup olmadığını değerlendirin.

İşe yarar bir sonuç: sorumlusu belli, gözden geçirme beklentileri net ve gerilemeyi fark edip sonraki adımı belirlemenize yardımcı olan ölçütler. Sürekli ölçüm hakkında daha fazla bilgi için sürecinizi sürekli nasıl izleyeceğinizi okuyun.

Uygulamalı örnek: Siparişten Tahsilata

Beş aşamanın Siparişten Tahsilata sürecine nasıl uygulanabileceğini görelim. Aşağıdaki rakamlar bir örneği gösterir, vaat edilen sonuçlar değildir.

Tanımla. Proje, tek bir ürün ailesi için Siparişten Tahsilata sürecini kapsar. Vaka, sipariş kabul edildiğinde başlar ve faturası ödendiğinde sona erer. CTQ’lar fatura doğruluğu ve tahsilat süresidir. Sorun tahsilatın gecikmesi olduğundan, sevkiyat yerine ödeme daha anlamlı bir bitiş noktasıdır.

Ölç. Ekip, sipariş numarasını kullanarak ERP ve faturalama sistemlerindeki olay verilerini birleştirir. Başlangıç değeri, siparişin kabulünden ödemeye kadar geçen sürenin medyanının 34 gün olduğunu gösterir. Bu sürenin 11 günü, faturanın oluşturulmasıyla gönderilmesi arasında geçer.

Analiz et. Gecikme belirli yollarda yoğunlaşır. Örnekte siparişlerin %22’si, dokuz gün ekleyen manuel bir kredi kontrolünden geçer; her altı faturadan biri yeniden düzenlenerek ödeme süresini baştan başlatır. Bu yolların hiçbiri belgelenmiş süreç modelinde yer almaz.

İyileştir. Ekip, manuel kontrollerin istisnalara odaklanması için kredi limitini yükseltmeyi değerlendirir. Geçmiş verilerle yapılan simülasyon, bu verilerde tahsili şüpheli alacakları artırmadan siparişlerin %18’inde dokuz gün kazandırabileceğini gösterir. Ekip yine de uygulama sonrasındaki gerçek performansı incelemelidir.

Kontrol et. Ekip, manuel yoldan geçen siparişlerin oranını izler ve inceleme için bir eşik belirler. Ölçümden sipariş masası sorumludur; Dashboardu süreçten sorumlu ekibin kullanımına açıktır.

Yalın süreç iyileştirmede sık karşılaşılan başarısızlıklar

Bir DMAIC projesi kâğıt üzerinde doğru adımları izlese de işe yarar bir değişiklik sağlayamayabilir. Şu örüntülere dikkat edin:

• Kuşak sisteminin yarattığı bürokrasi. Ekip, süreci veya verileri kontrol etmeden proje belgelerine zaman harcar. Proje tanımları ve paydaş haritaları yardımcı olabilir, ancak tek başlarına ilerlemenin kanıtı değildir.
• Savunulabilir bir başlangıç değerinin olmaması. Ölçüm aşaması atlanır veya yalnızca bir ankete dayanırsa Analiz aşamasında sınanacak fazla bir şey kalmaz. Başlangıç noktası olmadan daha sonra sağlıklı bir karşılaştırma yapamazsınız.
• Kapsamın program düzeyinde belirlenmesi. Geniş kapsamlı bir programın tek bir sorumlusu, vaka tanımı veya bir ekibin etkileyebileceği ölçümü olmayabilir. Kapsamı, sınırları ve sorumluluğu net bir süreçle daraltın.
• Analizden önce iyileştirmenin seçilmesi. Ekip otomatikleştireceği veya yeniden tasarlayacağı şeyi önceden kararlaştırdıysa, yalnızca bu kararı destekleyen kanıtları arayabilir. Önceden belirlenmiş bir çözümü haklı çıkarmak yerine, önerilen nedeni sınamak için Analiz aşamasını kullanın.
• Kontrol aşamasının olmaması. Proje bittikten sonra ölçümlerin sahibi olmazsa performans değişiklikleri fark edilmeyebilir. Projeyi kapatmadan önce sorumluyu, eşikleri ve gözden geçirme sıklığını belirleyin.

ProcessMind, DMAIC’in her aşamasını nasıl destekler?

ProcessMind; süreç verilerini incelemenize, süreç akışlarını belgelemenize, performansı analiz etmenize ve önerilen değişiklikleri simüle etmenize yardımcı olabilir. İnceleme sürecini destekler; hangi değişikliklerin yapılacağına ve bunların uygulanmasına ekibiniz karar verir. Bu yalın süreç iyileştirme araçları, süreç uzmanlığının veya sahipliğinin yerini almadan DMAIC döngüsüne kanıt ekler.

Aşamaların tümü ortak bir süreç tanımına dayanır. Her aşamada farklı veriler veya süreç görünümü kullanıldığında, ekibiniz iyileştirmeyi değerlendirmek yerine bu farklılıkları uzlaştırmak için zaman harcayabilir.

Analiz iş akışına genel bir bakış için süreç verilerinin nasıl analiz edileceğini inceleyin. Süreç modelleme ile Process Mining’in birbirini nasıl tamamladığını görmek için süreç modelleme ve Process Mining’in birlikte nasıl çalıştığını okuyun.

DMAIC projesine başlayın

Geniş kapsamlı bir iyileştirme hedefini, ekibinizin ölçebileceği bir projeye dönüştürmek için şu adımları izleyin. Bu yalın süreç iyileştirme modeli, ilk döngüyü ekibinizin tanımlayıp ölçebileceği ve gözden geçirebileceği bir sürece odaklar:

1. Sorumlusu belli bir süreç seçin. Sürecin sahibi yoksa Kontrol aşamasındaki sorumluluğu belirlemek zorlaşır.
2. Vaka tanımında anlaşın. Bir vakanın ne zaman başlayıp bittiğini kaydedin ve bu olayları hangi sistemlerin yakaladığını belirleyin.
3. İyileştirmeden önce ölçün. Atölye çalışmaları veya yeniden tasarım çalışmaları hedef durumu belirlemeden önce başlangıç değerini oluşturun.
4. İlk döngünün kapsamını dar tutun. Ekibinizin inceleyip gözden geçirebileceği bir kapsamla başlayın; ardından öğrendiklerinize göre sırada neyi inceleyeceğinize karar verin.

Değişikliği sınadıktan sonra iyileştirmeleri uygulamaya alın.

Buradan sonra ne yapabilirsiniz?

DMAIC projenize ölçülmüş bir başlangıç değeriyle başlayın.

DMAIC projenize ölçülmüş bir başlangıç değeriyle başlayın