30 saniyelik özet
To-Be Process, yani hedef durum süreci, belirlenen iş sonucuna ulaşmak için gelecekte nasıl çalışılacağını tanımlar. Faaliyetleri, karar koşullarını, sorumlulukları, sistem bağlantılarını ve istisnaları birlikte ele alır. Mevcut sürecin bütün adımlarını otomatikleştirmek zorunda değildir; gereksiz işleri kaldırabilir veya karar yetkisini yeniden düzenleyebilir. İyi bir hedef süreç, operasyonun nasıl değişeceğini ve bu değişime nasıl geçileceğini açıklar. Tasarımın başarısı, teslim edilen sistem kadar gerçekleşen iş sonucuyla değerlendirilir.
Neden önemli?
Bir onay formunu çevrimiçi yapmak, onay ihtiyacını veya beklemeyi ortadan kaldırmaz. Aynı kişiler aynı sırayla karar vermeye devam ediyorsa süreç dijitalleşmiş, fakat temel darboğaz değişmemiş olabilir. Hedef süreç tasarımı, “hangi ekranı yapacağız?” sorusundan önce hangi işin gerekli olduğunu ve kimin hangi kararı vermesi gerektiğini araştırır.
Bunun yönetim açısından önemli bir sonucu vardır. Yeni sistem, mevcut yetki düzenini değiştirmeden beklenen faydayı sağlayamayabilir. Yetki değişikliği ise yalnızca geliştirme ekibinin kararı değildir. Operasyon, kontrol ve sorumluluk düzeninin birlikte değerlendirilmesi gerekir. Teknik kapsam ile organizasyonel değişiklik birbirine bağlanmalıdır.
Junior bir iş analisti için To-Be, bulgularından uygulanabilir bir öneri üretme fırsatıdır. Mevcut sorunları sıralamak yetmez; önerilen akışın bunları nasıl azaltacağını açıklamak gerekir. Yönetici için ise hedef süreç, alternatif çalışma biçimlerini maliyet, fayda ve risk açısından karşılaştırmaya yardımcı olur.
Endüstri mühendisliği açısından amaç bir faaliyeti hızlandırmanın ötesindedir. Toplam akışın performansı önemlidir. Kontrolün kaldırılması süreyi azaltabilir, fakat yeniden işleme veya yanlış işlem maliyetini artırabilir. Bu nedenle hedef süreç, iyileşmenin hangi koşullarda işletme açısından değerli olacağını da göstermelidir.
Terim nedir?
As-Is, mevcut işleyişi; To-Be ise önerilen gelecek işleyişini temsil eder. İkisi arasındaki fark, yalnızca yeni sistemin eklenmesi değildir. Faaliyetler kaldırılabilir, birleştirilebilir veya başka bir role taşınabilir. Bazı kararlar kurallarla verilirken belirsiz ya da yüksek etkili durumlar insan değerlendirmesinde kalabilir.
Tasarımın başlangıcı iş hedefidir. İade süresini azaltmak, müşteri tekrar temasını azaltmak veya işlem doğruluğunu artırmak farklı öncelikler yaratabilir. Bir akışın başka bir işletmede başarılı olması, burada aynı hedefe katkı sağlayacağını göstermez. Önerinin kendi bağlamındaki problem ve kısıtlarla ilişkilendirilmesi gerekir.
Hedef süreçte her önemli geçişin koşulu açıklanmalıdır. “Sistem otomatik onaylar” cümlesi yeterli değildir. Hangi bilgiyle, hangi kuralı uygulayarak, hangi yetki sınırında karar verileceği belirlenmelidir. Gerekli veri yoksa veya işlem tamamlanamazsa ne yapılacağı da tasarımın parçasıdır.
Entegrasyon, yani sistemlerin bilgi ve işlem alışverişi kurması, bu akışın uygulanabilirliğini etkiler. Bir sistemde tamamlanan işlem diğerine geç ulaşabilir. Bu nedenle işin hangi durumda bekleyeceği, tekrar deneneceği veya müdahaleye yönlendirileceği açıklanmalıdır. Müşteriye gösterilen durum ile işletmenin bildiği durum arasında tutarlılık aranır.
Tek bir gelecek durum modeli her zaman yeterli olmayabilir. Önce uygulanabilir bir geçiş süreci, ardından daha kapsamlı bir hedef tasarlanabilir. Geçişte elle yürütülen bazı adımların devam etmesi mümkündür. Bunların sorumlusu ve hangi koşulda kaldırılacağı belirlenmezse geçici çözüm kalıcı hâle gelebilir.
To-Be modeli bir sonuç garantisi değildir. Önerilen çalışma biçiminin fayda yaratacağına ilişkin varsayımları gösterir. Kullanıcıların yeni akışı benimsemesi, veri kalitesi ve operasyonel kapasite gibi koşullar doğrulanmalıdır. Tasarım, uygulama sırasında öğrenilenlerle gözden geçirilebilir.
Gerçek vaka: SV Group ve likeMagic’in konaklama deneyimi
Camunda’nın SV Group ve likeMagic vaka anlatımı, misafir ve çalışan deneyimini birlikte ele alan dijital konaklama platformunu açıklıyor. Misafirin rezervasyon, giriş, hizmet talebi ve çıkış işlemlerinin bağlantılı bir deneyim içinde yürütülmesi hedeflenmiş. Çalışanların da tekrarlı idari işlere daha az zaman ayırarak misafirlere odaklanması amaçlanmış.
Farklı bulut hizmetlerinin birlikte çalışması ve süreçteki sorunların zamanında fark edilmesi önemli ihtiyaçlar olmuş. Kaynak, kritik adımlardaki gecikme veya başarısızlıkların izlenmesini ve ekibin uyarılmasını anlatıyor. Ayrıca çalışmanın pasif süreç izlemeyle başladığını, daha etkin süreç yönetimine geçişin sonraki planlar arasında bulunduğunu belirtiyor.
Bu vaka, hedef sürecin yalnızca formu dijitalleştirmekten daha geniş olabileceğini gösteriyor: Müşterinin işi tamamlama biçimiyle çalışanın sorumlulukları birlikte tasarlanmış. Bununla birlikte kaynak sağlayıcının müşteri anlatımıdır. Gelecek planlarını tamamlanmış uygulamalar olarak değerlendirmemek ve anlatılan sonuçları tek bir tasarım tercihine bağlamamak gerekir.
Varsayımsal örnek: İade sürecini yeniden tasarlamak
Bir e-ticaret işletmesinde müşteri iade talebi açıyor, destek ekibi bilgileri kontrol ediyor, depo ürünü inceliyor ve finans geri ödeme işlemini yapıyor olsun. İlk öneri bütün talepleri aynı sırayla ilerleten yeni bir iade ekranı hazırlamak olsun.
Mevcut durum araştırmasında bazı kontrollerin farklı ekiplerce tekrarlandığı ve eksik bilgi nedeniyle taleplerin geri gönderildiği görülebilir. Hedef süreç, bu bulguları azaltacak seçeneklerle tasarlanır. Talep başlangıcında hangi bilginin gerekli olduğu ve hangi aşamada gerçekten doğrulanabileceği ayrılır. Müşteriden işletmenin zaten sahip olduğu bilgi tekrar istenmez.
Analist, destek, depo ve finansla karar koşullarını inceler. Bazı işlemler tanımlı kurallarla ilerleyebilir; bazıları inceleme gerektirebilir. Hangi talebin hangi yola gideceği, işletmenin doğrulanmış kurallarına dayanmalıdır. Bu örnekte belirli bir tutar veya müşteri davranışı eşiği vermiyoruz; böyle bir sınır veri ve yetkili karar olmadan belirlenemez.
Hedef modelde her aşamanın çıktısı tanımlanır. Depo incelemesi tamamlandığında hangi bilgi finansın işlem yapmasını sağlar? Ödeme hizmetinden cevap alınamazsa işlem başarısız mı, sonucu belirsiz mi sayılır? Belirsiz bir işlemi yeniden başlatmadan önce nasıl kontrol yapılacağı açıklanır. Böylece aynı geri ödemenin tekrarlanması gibi riskler değerlendirilir.
Yeni süreçte müşteriye durum bilgisi verilmesi ve istisnaların sorumlu ekibe yönlendirilmesi planlanır. Ancak bildirim göndermek tek başına beklemeyi azaltmaz. Bekleyen talebin kim tarafından ve hangi koşulda ele alınacağı belirlenir. Süreç, iletişim ile işin ilerlemesini ayrı ihtiyaçlar olarak ele alır.
Geçiş öncesinde örnek senaryolar yürütülür. Normal iade, eksik bilgi, inceleme uyuşmazlığı ve ödeme sonucu belirsizliği değerlendirilir. Sınırlı uygulama sonrasında tamamlanma süresi, tekrar temas ve yanlış işlem göstergeleri incelenebilir. Yeni akışın hız kazandırırken kontrol kalitesini koruduğu, ölçümle değerlendirilmelidir.
Yaygın üç hata
- Mevcut bütün adımları otomatikleştirmek. Bir adımın bugün yapılıyor olması, gelecekte gerekli olduğunu kanıtlamaz. Önce amacı ve koruduğu ihtiyacı araştırın. Gereksiz işi kaldırmak veya tekrarlı kontrolü birleştirmek, aynı işi daha hızlı yaptırmaktan farklı bir tasarım seçeneğidir.
- Yalnızca sorunsuz akışı tasarlamak. Veri gelmediğinde, onay geciktiğinde veya sistem bağlantısı çalışmadığında operasyon devam etmek zorundadır. İstisnaların sorumlusu ve geri dönüş yolu belirlenmelidir. Bunlar sonradan eklenecek ayrıntılar değil, hedef sürecin uygulanabilirlik koşullarıdır.
- Geçişi ve sonuç sahibini belirsiz bırakmak. Yeni akış çizilmiş olabilir; ancak mevcut işler, eski kayıtlar ve kullanıcıların çalışma alışkanlıkları kendiliğinden değişmez. Geçişte kimin hangi işi yapacağı belirlenmelidir. Uygulama sonrasında sonucu değerlendirecek ve sapmada karar verecek kişi de açık olmalıdır.
Mini uygulama: Hedef süreç karar kartı
Bir iyileştirme önerisini geliştirme kapsamına almadan önce aşağıdaki kartı doldurun. Her önemli değişikliği mevcut sorunla ilişkilendirin.
- İş hedefi
- Hangi sonuç değişmeli?
- Mevcut sorun
- Hangi kanıt değişikliği gerekli kılıyor?
- Önerilen akış
- İş gelecekte nasıl ilerleyecek?
- Kaldırılan veya değişen iş
- Hangi faaliyet neden farklılaşıyor?
- Karar yetkisi
- Kuralları ve istisnaları kim onaylıyor?
- Veri ve sistem ihtiyacı
- Hangi bilgi nerede gerekli?
- Başarısızlık yolu
- İş tamamlanamazsa ne yapılacak?
- Geçiş düzeni
- Mevcut işler yeni akışa nasıl taşınacak?
- Başarı ve koruyucu ölçü
- Fayda ve olası yan etki nasıl izlenecek?
- Sonuç sahibi
- Uygulama sonrası kararı kim verecek?
Kartı tamamladıktan sonra öneriyi gerçekçi senaryolarla yürütün. Her adımda gerekli bilginin mevcut olup olmadığını ve sorumlu rolün işi yapıp yapamayacağını kontrol edin. Hedef süreç, geleceği kusursuz çizdiğinde değil, uygulanabilir bir çalışma biçimini ve sınanabilir fayda beklentisini açıkladığında karar için kullanılabilir olur.
İlgili terimler
As-Is Process, Process Mapping ve BPMN, Business Objective, Gap Analysis, Business Rule, Stakeholder Analysis, Functional Requirement, Non-Functional Requirement, Acceptance Criteria, Change Request ve Impact Analysis, Benefits Realization Management