Süreç dönüşümünde en sık kullanılan kavramlardan ikisi As-Is ve To-Be'dir.
As-Is, sürecin bugün nasıl yürüdüğünü ifade eder.
To-Be, gelecekte nasıl çalışmasını istediğimizi tanımlar.
Tanım basittir. İyi bir To-Be tasarlamak ise yalnızca yeni bir süreç diyagramı çizmekten daha fazlasını gerektirir.
As-Is neden gereklidir?
Mevcut durumu anlamadan hedef süreç tasarlamak, yanlış probleme çözüm üretme riskini artırır.
As-Is çalışmasının amacı mevcut süreci savunmak değildir.
Amaç:
- işin gerçekten nasıl yapıldığını,
- hangi kontrollerin neden bulunduğunu,
- nerede bekleme oluştuğunu,
- hangi istisnaların bulunduğunu,
- hangi manuel işlerin yapıldığını,
- sistemlerin nasıl etkileştiğini
anlamaktır.
Bunun için görüşmeler, workshop'lar, süreç modelleri, KPI ve raporlar, Process Mining ve Task Mining birlikte kullanılabilir.
As-Is'i yeterince anlamadan tasarlanan To-Be, gerçek problemin yerine varsayılan problemi çözebilir.
As-Is'i olduğu gibi dokümante etmek yeterli midir?
Hayır.
Bir As-Is çalışması yalnızca “bugün ne yapıyoruz?” sorusuna değil, “neden böyle yapıyoruz?” sorusuna da cevap aramalıdır.
Bazı adımlar regülasyon nedeniyle zorunlu olabilir.
Bazıları geçmişteki bir problemin çözümü olarak eklenmiş fakat bugün artık gereksiz hale gelmiş olabilir.
Bu ayrım To-Be tasarımının kalitesini belirler.
To-Be nasıl tasarlanmalı?
İlk soru “hangi teknolojiyi kullanalım?” olmamalıdır.
Önce:
- Hangi adımlar kaldırılabilir?
- Hangi kontroller gerekli?
- Hangi karar noktaları sadeleştirilebilir?
- Hangi işler paralel yürüyebilir?
- Roller doğru yerde mi?
- Hangi handoff'lar gereksiz?
- Hangi manuel işler azaltılabilir?
- Hangi alanlar otomasyona uygun?
- İstisnalar nasıl yönetilecek?
soruları değerlendirilmelidir.
Teknoloji bu tasarımı desteklemelidir.
To-Be mümkün olduğunca farklı mı olmalı?
Hayır.
Mevcut süreçte iyi çalışan bölümler olabilir.
Amaç olabilecek en radikal süreci tasarlamak değil, belirlenen problemi çözen, uygulanabilir ve ölçülebilir biçimde daha iyi bir süreç tasarlamaktır.
To-Be tasarımı mevcut süreci dijital ortama taşımak değil; gerekli olanı koruyup gereksiz olanı yeniden düşünmektir.
Kontroller ve risk nasıl ele alınmalı?
Süreç sadeleştirme kontrol kaldırmakla eş anlamlı değildir.
Bir kontrol gerçekten risk azaltıyorsa korunmalıdır.
Asıl soru:
- kontrol doğru yerde mi,
- aynı kontrol birden fazla kez mi yapılıyor,
- otomatikleştirilebilir mi,
- risk bazlı uygulanabilir mi?
olmalıdır.
Simulation / What-if nasıl kullanılabilir?
To-Be tasarımı uygulanmadan önce farklı senaryoların etkisi modellenebilir.
Örneğin onay kaldırılırsa, kaynak sayısı artırılırsa, aktiviteler paralelleştirilirse veya otomasyon eklenirse bekleme ve toplam süreç süresi nasıl etkilenebilir?
Simülasyon kesin gelecek tahmini değildir; karar öncesi alternatifleri karşılaştırmaya yardımcı olur.
Başarı kriterleri baştan belirlenmeli
To-Be tasarlanırken hedef göstergeler de belirlenmelidir.
Uçtan uca süre, bekleme, hata, rework, manuel efor, SLA, müşteri sonucu ve uyum gibi göstergeler başlangıçta tanımlanabilir.
Yeni süreç ancak uygulama sonrasında bu göstergeler üzerinden değerlendirildiğinde gerçekten daha iyi olup olmadığı anlaşılabilir.
← Tüm yazılar