30 saniyelik özet
As-Is Process, yani mevcut durum süreci, bir işin bugün gerçekte nasıl yürüdüğünü gösterir. Rolleri, faaliyetleri, kullanılan sistemleri, kararları, beklemeleri ve istisnaları birlikte ele alır. Amaç mevcut işleyişi çizmekle yetinmek değil; değişikliğin hangi sorunu çözeceğini ve etkisinin nasıl değerlendirileceğini belirlemektir. Prosedür, görüşme, gözlem ve işlem kayıtları birlikte incelenir. Resmî akışın dışındaki yöntemler de modele eklenir; çünkü işin sonucu bunlara bağlı olabilir.
Neden önemli?
Bir sipariş süreci “sipariş alındı, hazırlandı, gönderildi” diye anlatılabilir. Bu anlatım doğru olsa da iyileştirme kararı için yetersizdir. Sipariş ödeme kontrolünde mi bekliyor, stok kaydı mı uyuşmuyor, depo hazırlığı mı gecikiyor? Her neden farklı bir müdahale gerektirir. Ayrıntılar bilinmeden seçilen çözüm, sorunun bulunduğu noktaya dokunmayabilir.
Yeni bir ekranın veri girişini hızlandırması, toplam işlem süresini aynı ölçüde azaltmayabilir. İşin büyük bölümü onay bekleyerek geçiyorsa veri girişindeki iyileşme sınırlı kalır. Mevcut durum analizi, işin yapıldığı süre ile beklediği süreyi ayırarak yatırımın nereye yönelmesi gerektiğini değerlendirmeye yardımcı olur.
Junior bir iş analisti için bu çalışma, kullanıcı anlatısını süreç modeline dönüştürme becerisidir. Yönetici için ise işletmenin performansını etkileyen bağımlılıkları görme aracıdır. Hangi ekipte sorun olduğu sorusunu, hangi koşulların hangi noktada bekleme veya yeniden işleme ürettiği sorusuyla birlikte ele almayı sağlar.
Endüstri mühendisliği açısından mevcut durum, iyileştirme öncesindeki karşılaştırma temelidir. Başlangıç ölçümü ve süreç sınırı bilinmezse uygulama sonrasında oluşan değişimi yorumlamak zorlaşır. Daha hızlı sonuç alınmış olabilir; ancak müşteri grubu, işlem türü veya hacim de değişmiş olabilir. Süreç modeli bu farkları araştırmak için bağlam sağlar.
Terim nedir?
As-Is, mevcut işleyişin belirli bir kapsam ve zaman içindeki temsilidir. To-Be, yani hedef durum süreci, ileride nasıl çalışılması istendiğini gösterir. Mevcut durum analizine hedef çözümün kurallarını eklemek, bugün yaşanan sorunların görünmesini engelleyebilir. İki modelin hangi durumu anlattığı açıkça belirtilmelidir.
Bir mevcut durum modeli yalnızca faaliyet kutularından oluşmaz. İşin hangi olayla başladığı, hangi koşulda tamamlandığı, kararların kim tarafından verildiği ve hangi bilginin kullanıldığı da önemlidir. “Finans kontrol eder” ifadesi yerine neyin kontrol edildiği, hangi sonuçların mümkün olduğu ve sonucun sonraki adıma nasıl aktarıldığı açıklanmalıdır.
Modelin ayrıntı seviyesi, araştırılan probleme göre seçilir. Sipariş gecikmesini anlamak için bütün şirketin süreçlerini çizmek gerekmez. Ancak gecikmeye etki eden ödeme, stok ve onay bağımlılıklarını kapsam dışında bırakmak da yanlış sonuca götürebilir. Başlangıç ve bitiş sınırları, analiz amacına uygun olmalıdır.
Gayriresmî yollar da mevcut durumun parçasıdır. Çalışanın e-posta üzerinden onay alması, ayrı bir dosyada takip yapması veya sistem hatasını elle düzeltmesi, işin fiilen tamamlanmasını sağlıyor olabilir. Bu davranışları modelden çıkarmak, yeni çözümün bugün karşılanan bir ihtiyacı gözden kaçırmasına yol açabilir.
Model, gözlenen durum ile doğrulanmamış anlatımı ayırt etmelidir. “Bazen sipariş bekliyor” bir araştırma başlangıcıdır. Hangi siparişin, hangi koşulda ve ne kadar beklediğini gösteren kayıt ise daha somut kanıttır. Kayıt bulunmayan faaliyetlerde belirsizlik açıklanmalı; eksik bilgi ölçülmüş gibi sunulmamalıdır.
Gerçek vaka: R-KOM’da destek kaydından teknisyen müdahalesine
Camunda’nın yayımladığı R-KOM vakası, mesai dışındaki teknik destek taleplerinde yaşanan beklemeyi anlatıyor. Eski süreçte müşteri araması veya e-postası destek sistemine kaydediliyor, ardından kayıt bir teknisyen tarafından elle seçiliyormuş. Sorunun teşhis edilmesi bu adım sonrasında başlayabiliyormuş.
Kaynak, sürecin yoğun manuel iş içerdiğini ve iyileştirme için görünürlüğünün sınırlı olduğunu belirtiyor. Teknisyenlerin kendi teşhis araçlarını yönetmesi de mühendislik ekibinin süreci bütünüyle anlamasını ve otomasyona taşımasını zorlaştırmış. Çözümün tasarlanması, teknisyenlerle bilgi teknolojileri ekibinin birlikte çalışmasını gerektirmiş.
Bu vaka, bütün sorunun destek ekranına indirgenemeyeceğini gösteriyor. Kayıt oluşturma, işi seçme ve teşhis etme arasındaki bağlantılar, müşteri beklemesini etkiliyor. Mevcut durum açısından çıkarılabilecek ders, sistemde görünen adımlarla operasyonun tamamının aynı olmadığıdır. Kaynak otomasyon sağlayıcısının müşteri anlatımıdır; belirli bir As-Is çalışmasının etkisini ayrı ve bağımsız olarak ölçmüyor.
Varsayımsal örnek: Geciken e-ticaret siparişleri
Bir e-ticaret işletmesinde bazı siparişlerin geç gönderildiğini düşünelim. İlk öneri depo çalışanlarına yeni bir görev ekranı hazırlamak olsun. İş analisti bu öneriyi değerlendirmek için önce geciken siparişlerin mevcut yolculuğunu inceler.
Süreç sınırı, siparişin alınmasından kargo firmasına teslim edilmesine kadar belirlenir. Ödeme onayı, stok ayırma, hazırlama, paketleme ve teslim kayıtları incelenir. Ancak sistemdeki zaman damgalarının anlamı da doğrulanır: Bir kaydın oluşturulma zamanı, fiziksel işlemin tamamlanma zamanı olmayabilir. Yanlış olayları karşılaştırmak, beklemenin yanlış yerde görünmesine neden olabilir.
Analist, farklı sipariş türlerini kapsayan kayıtları seçer ve işi yapan kişilerle örnekler üzerinden ilerler. Yalnızca geciken siparişlere bakmak yerine zamanında tamamlanan işlemleri de inceler. Böylece gecikmeyle ilişkili koşulların, normal işleyişten hangi noktalarda ayrıldığı araştırılabilir.
Gözlemde, stok uyuşmazlığı bulunan siparişler için depo çalışanının ayrı bir mesajlaşma kanalından karar istediği ortaya çıkabilir. Bu karar sisteme kaydedilmediğinden sipariş görev listesinde bekliyor görünürken gerçek engel stok düzeltme onayıdır. Resmî prosedürde bulunmayan bu adım modele eklenir.
Ardından onayın kimden istendiği, hangi bilgiye dayandığı ve cevap gelmediğinde ne yapıldığı araştırılır. “Depo geç hazırlıyor” şeklindeki genel açıklama, daha belirli bir soruya dönüşür: Stok uyuşmazlığı durumunda kararın alınması ve kaydın güncellenmesi neden bekleme yaratıyor? Bu soru, çözüm seçeneklerini daha doğru sınırlar.
Mevcut durum modeli; normal akışı, uyuşmazlık yolunu, sorumlu rolleri ve kayıt eksiklerini birlikte gösterir. Hedef çözüm henüz seçilmez. Sonraki aşamada yetki düzeni, stok güncelleme yöntemi veya sistem bildirimleri değerlendirilebilir. Yeni görev ekranının gerekli olup olmadığı da bu bulgularla yeniden ele alınır.
Yaygın üç hata
- Prosedürü gerçek süreç kabul etmek. Yazılı prosedür, beklenen davranışı gösterebilir; günlük uygulama farklı olabilir. İşi yapan kişilerle örnek kayıtlar üzerinden ilerlemek ve mümkünse gözlem yapmak gerekir. Farklar hemen kural ihlali diye yorumlanmamalı; neden ortaya çıktıkları araştırılmalıdır.
- Yalnızca sorunsuz akışı çizmek. İstisnalar, yeniden işleme ve sistem dışı kontroller görünmezse model eksik kalır. Her nadir olayı aynı ayrıntıda incelemek gerekmez; fakat araştırılan problemle ilişkili yollar mutlaka gösterilmelidir. Kapsam kararı, olayın sıklığı ve etkisi birlikte düşünülerek verilmelidir.
- Mevcut durumla çözümü aynı modele koymak. Analiz sırasında “buraya otomatik onay ekleyelim” demek yararlı bir fikir üretebilir; ancak bugünkü akışı değiştirmez. Öneriler ayrı kaydedilmelidir. Aksi hâlde ekip, hangi adımın gözlendiğini ve hangisinin henüz tasarım fikri olduğunu ayırt edemez.
Mini uygulama: Mevcut durum inceleme kartı
Bir süreci analiz ederken aşağıdaki kartı doldurun. Önce kapsamı belirleyin, ardından gerçek bir işlemi bu sınırlar içinde baştan sona izleyin.
- Analiz amacı
- Hangi problem veya karar için inceliyoruz?
- Başlangıç olayı
- Süreç hangi olayla başlıyor?
- Bitiş koşulu
- İşletme açısından ne zaman tamamlanıyor?
- Roller ve sistemler
- Kim, hangi araçla işlem yapıyor?
- Kararlar
- Hangi koşul farklı bir yol oluşturuyor?
- Beklemeler
- İş nerede, neyi bekliyor?
- İstisnalar
- Hangi durumda manuel müdahale gerekiyor?
- Ölçüm
- Hangi olaylar ve kayıtlar karşılaştırılıyor?
- Kanıt
- Model hangi gözlem veya kayıtla destekleniyor?
- Belirsizlik
- Hangi adım henüz doğrulanmadı?
Modeli kullanıcılar ve süreç sahibiyle gözden geçirin. Özellikle devir noktalarında, bir ekibin işi tamamlanmış saydığı anın diğer ekip için ne anlama geldiğini kontrol edin. Mevcut durum çalışması, bütün ayrıntılar çizildiğinde değil, karar için gerekli işleyiş ve bilgi boşlukları anlaşılır hâle geldiğinde kullanılabilir olur.
İlgili terimler
To-Be Process, Process Mapping ve BPMN, Domain Knowledge, Requirements Elicitation, Stakeholder Analysis, Root Cause Analysis, Gap Analysis, Business Rule, Data Mapping ve Data Dictionary, KPI ve Metrics, Dependency Management