İş Süreci Analizi Özel Yazılım Projesinden Önce Nasıl Yapılır?

Özel yazılım projesinden önce iş süreci analizi yapmak, “hangi ekranları yapacağız?” sorusuna cevap aramak değildir. Asıl amaç, işletmenin bugün işi nasıl yürüttüğünü, nerede zaman kaybettiğini, hangi verilerin tekrar girildiğini, hangi onayların aksadığını, hangi istisnaların manuel çözüldüğünü ve yazılımın hangi problemi çözmesi gerektiğini netleştirmektir.

Analiz yapılmadan başlanan projelerde yazılım ekibi genellikle ekran listesiyle ilerler. Müşteri panel ister, CRM ister, stok ister, rapor ister; fakat sürecin nerede başladığı, kimden kime geçtiği, hangi bilgiyle tamamlandığı ve hatalı durumda ne olacağı net değildir. Sonuçta yazılım çalışır görünür ama gerçek operasyonu taşımakta zorlanır.

İş süreci analizi nedir?

İş süreci analizi, bir işin başlangıçtan sonuca kadar hangi adımlarla, kimler tarafından, hangi verilerle ve hangi kurallarla yürütüldüğünü anlamaya yönelik çalışmadır. Bu analiz, yazılım projesinde yalnızca teknik gereksinim üretmez; işletmenin çalışma biçimini görünür hale getirir.

IIBA’nın BABOK sayfası, iş analizini iş ihtiyaçlarını anlamak ve paydaşlara değer sağlayan çözümleri önermek için kullanılan uygulamalar bütünü olarak konumlandırır IIBA BABOK. Özel yazılım bağlamında bu, yazılımın yalnızca talep edilen özellikleri değil, gerçek iş ihtiyacını karşılaması gerektiği anlamına gelir.

İş süreci otomasyonu projelerinde analiz özellikle kritiktir. Çünkü otomasyon, kötü tasarlanmış bir süreci hızlandırırsa hata daha hızlı yayılır. Önce sürecin kendisi anlaşılmalı, sonra hangi adımların yazılıma taşınacağı belirlenmelidir.

Analize kimler katılmalı?

İş süreci analizi yalnızca yöneticiyle yapılan toplantıdan ibaret olmamalıdır. Yönetici hedefi bilir; fakat günlük operasyonu çoğu zaman sahadaki kullanıcılar taşır. Satış temsilcisi, muhasebe personeli, destek ekibi, depo sorumlusu, bayi yöneticisi, müşteri temsilcisi ve teknik ekip farklı gerçekleri görür.

Analize katılması gereken paydaşlar proje türüne göre değişir:

• İş sahibi veya yönetici: hedef, bütçe, öncelik ve başarı kriteri için
• Operasyon kullanıcısı: günlük iş akışı ve istisnalar için
• Departman sorumlusu: onay, rol ve raporlama ihtiyaçları için
• Teknik ekip: mevcut sistem, veri ve entegrasyonlar için
• Muhasebe veya finans: ödeme, fatura, cari ve mali süreçler için
• Müşteri destek ekibi: talep, şikayet ve takip süreçleri için

Yalnızca karar vericiyle yapılan analiz, yazılımın stratejik hedefini netleştirebilir; ancak günlük kullanım detaylarını kaçırabilir. Yalnızca kullanıcıyla yapılan analiz ise yönetim hedefini ve ölçüm kriterini eksik bırakabilir. Bu nedenle iki taraf da sürece dahil edilmelidir.

Mevcut süreç nasıl haritalanır?

İlk adım mevcut süreci, yani “as-is” durumu çıkarmaktır. Bu aşamada amaç hemen çözüm önermek değil, bugün işin gerçekten nasıl yürüdüğünü anlamaktır. Süreç ideal anlatıma göre değil, gerçek hayattaki akışa göre yazılmalıdır.

BPMN, iş süreçlerini görsel olarak modellemek için kullanılan standart bir notasyondur. OMG, BPMN’nin iş süreçlerini tasarlayan, yöneten ve gerçekleştiren paydaşlar tarafından doğrudan kullanılmak üzere tasarlandığını ve uygulama ortamından bağımsız, akış şeması benzeri bir gösterim sunduğunu açıklar OMG BPMN. Özel yazılım analizinde BPMN’in tüm karmaşık sembollerini kullanmak şart değildir; fakat süreç akışını ortak bir görsel dilde göstermek çok faydalıdır.

Mevcut süreç haritasında şu bilgiler yer almalıdır:

• Sürecin başlangıç noktası
• Her adımı yapan kişi veya rol
• Kullanılan belge, form veya sistem
• Karar noktaları ve onaylar
• Bekleme, geri dönüş ve hata durumları
• Sürecin tamamlandığı nokta
• Manuel yapılan tekrar işler

Aktörler ve roller nasıl çıkarılır?

İş süreci analizinde aktör, sürece dahil olan kişi, departman, müşteri, dış sistem veya entegrasyondur. Aktörleri doğru çıkarmak, ileride kullanıcı rolleri, erişim izinleri ve ekran akışları için temel oluşturur.

Örneğin teklif yönetimi sürecinde aktörler şöyle olabilir: satış temsilcisi, satış müdürü, müşteri, muhasebe, yönetici ve CRM sistemi. Randevu sürecinde müşteri, çağrı merkezi, uzman personel, takvim sistemi ve bildirim servisi aktör olabilir. B2B sipariş sürecinde bayi, satış ekibi, depo, muhasebe, kargo ve ERP devreye girer.

Bu aşamada yalnızca “kim kullanacak?” sorusu yetmez. “Kim bilgi giriyor, kim onaylıyor, kim sadece görüyor, kim hata olduğunda müdahale ediyor?” soruları da sorulmalıdır.

Veri akışı analiz edilmeden yazılım tasarlanmaz

Bir süreçte hangi verinin nerede üretildiği ve nerede kullanıldığı bilinmeden sağlıklı yazılım tasarlanamaz. Müşteri adı, vergi numarası, ürün kodu, stok miktarı, teklif tutarı, ödeme durumu, dosya eki, teslimat adresi veya onay notu hangi adımda oluşuyor? Bu veri başka bir sisteme gidiyor mu? Sonradan değişirse hangi kayıtlar etkileniyor?

API entegrasyon hizmeti gerektiren projelerde veri akışı daha da önemlidir. CRM, muhasebe, e-ticaret, ödeme, kargo, stok veya ERP sistemleri arasında veri taşınacaksa her alanın kaynağı, formatı ve sorumlusu belirlenmelidir.

Darboğaz ve tekrar işler nasıl bulunur?

İş süreci analizinin değeri, yalnızca mevcut akışı çizmek değil, darboğazları görünür kılmaktır. Bir onay sürekli bekliyorsa, aynı veri üç farklı yere giriliyorsa, müşteri bilgisi e-posta ile taşınıyorsa, rapor manuel hazırlanıyorsa veya destek talebi kişisel mesajlarda kayboluyorsa yazılım projesi bu noktaları hedeflemelidir.

Darboğazları bulmak için şu sorular kullanılabilir:

• En çok hangi adımda bekleme oluyor?
• Hangi bilgi birden fazla kez giriliyor?
• Hangi işlem kişiye bağlı ilerliyor?
• Hangi karar için veri eksik kalıyor?
• Hangi hata en sık tekrar ediyor?
• Hangi işlem müşteriye geç dönülmesine neden oluyor?
• Hangi rapor manuel hazırlanıyor?

Bu soruların cevabı, yazılım kapsamını doğrudan etkiler. Çünkü her süreç dijitalleştirilmeyi hak etmeyebilir; önce en pahalı, en hatalı veya en yavaş adımlar ele alınmalıdır.

İstisna senaryoları mutlaka yazılmalı

Süreçler çoğu zaman ideal akışa göre anlatılır: müşteri form doldurur, satış arar, teklif hazırlanır, müşteri onaylar, ödeme alınır. Gerçek hayatta ise müşteri eksik bilgi verir, teklif revize olur, ödeme bekler, stok yetmez, onay gecikir, entegrasyon hata verir veya işlem iptal edilir.

Özel yazılım analizinde istisnalar yazılmazsa yazılım yalnızca “mutlu yol” için çalışır. Canlı kullanımda ise en çok destek talebi istisnalardan gelir. Bu nedenle her ana akış için hata, iptal, revizyon, bekleme, geri dönüş ve manuel müdahale senaryoları sorulmalıdır.

Hedef süreç nasıl tasarlanır?

Mevcut süreç çıkarıldıktan sonra hedef süreç, yani “to-be” akış tasarlanır. Hedef süreç, mevcut sürecin birebir dijital kopyası olmak zorunda değildir. Gereksiz adımlar kaldırılabilir, onaylar sadeleştirilebilir, veri tekrarları azaltılabilir, bazı bildirimler otomatikleşebilir.

Burada dikkat edilmesi gereken nokta, yazılımı mevcut karmaşayı otomatikleştirmek için kullanmamaktır. Eğer süreçte gereksiz onay, çift veri girişi veya belirsiz sorumluluk varsa önce iş akışı sadeleştirilmelidir. Yazılım bu sadeleşmiş akışı desteklemelidir.

Özel web yazılım hizmeti bu yüzden yalnızca kodlama işi değildir. Doğru proje, işletmenin bugün nasıl çalıştığını ve yarın nasıl çalışmak istediğini birlikte ele alır.

Service blueprint ne zaman işe yarar?

Bazı süreçlerde müşteri deneyimi ile arka ofis operasyonu birlikte düşünülmelidir. Örneğin müşteri portalı, randevu sistemi, destek talebi, onboarding, rezervasyon veya servis süreçlerinde müşteri ekranda bir işlem yaparken arka tarafta personel, bildirim, belge, ödeme veya onay akışı çalışır.

Nielsen Norman Group, service blueprint’i kullanıcı ile hizmet sağlayıcı arasındaki temas noktalarını ve sahne arkası süreçleri görselleştiren bir diyagram olarak açıklar Nielsen Norman Group. Özel yazılım analizinde bu yaklaşım, müşteri ekranı ile operasyon paneli arasındaki bağlantıyı netleştirmek için faydalıdır.

Örneğin müşteri “talep aç” butonuna basar. Ön yüzde bu basit bir formdur; arka tarafta talep numarası oluşur, departman atanır, bildirim gider, SLA başlar, müşteri geçmişine kayıt düşer ve raporlama verisi oluşur. Service blueprint bu görünür ve görünmez adımları aynı anda düşünmeye yardımcı olur.

Entegrasyon ihtiyacı nasıl belirlenir?

İş süreci analizi, entegrasyon ihtiyacını erken ortaya çıkarmalıdır. Hangi veri başka sistemden gelecek, hangi işlem başka sisteme gidecek, hangi sistem ana kaynak olacak, hata durumunda ne yapılacak? Bu sorular netleşmeden yazılım kapsamı eksik kalır.

Örneğin ödeme takibi projesinde sanal POS, fatura entegratörü ve muhasebe sistemi devreye girebilir. Stok takip projesinde ERP, e-ticaret sitesi ve depo terminali bağlantısı gerekebilir. CRM projesinde web formu, e-posta pazarlama aracı ve teklif sistemi entegre olabilir.

Entegrasyon analizi yapılırken API dokümantasyonu, test ortamı, veri formatı, kimlik doğrulama yöntemi, hata kodları, rate limit ve webhook desteği kontrol edilmelidir.

Modül kapsamı nasıl önceliklendirilir?

İş süreci analizi sonunda çoğu zaman uzun bir ihtiyaç listesi oluşur. Her ihtiyacın ilk faza girmesi gerekmez. Önceliklendirme yapılırken iş etkisi, risk, kullanım sıklığı, manuel iş yükü, geliştirme maliyeti ve bağımlılık değerlendirilmelidir.

Yazılım geliştirme sürecinde iyi analiz, MVP veya faz planını daha sağlıklı hale getirir. Önce ana değer akışı çalışmalı, sonra rapor, otomasyon, gelişmiş yetki ve entegrasyonlar fazlara ayrılmalıdır.

Analiz çıktısı ne olmalı?

Bu blogun konusu gereksinim dokümanı hazırlamak değil; ancak iş süreci analizinin somut çıktıları olmalıdır. Analiz toplantıları yalnızca konuşma olarak kalırsa proje ilerledikçe unutulur veya farklı yorumlanır.

Analiz sonunda şu çıktılar hazırlanabilir:

• Mevcut süreç haritası
• Hedef süreç taslağı
• Aktör ve rol listesi
• Veri alanları ve veri kaynağı listesi
• İstisna ve hata senaryoları
• Entegrasyon ihtiyaçları
• Darboğaz ve risk listesi
• Önceliklendirilmiş modül listesi
• İlk faz ve sonraki faz ayrımı

Gereksinim dokümanı bir sonraki aşamada bu analiz çıktılarından beslenir. Bu ayrım önemlidir: analiz “işi anlamak”, doküman ise “yazılım kapsamını tarif etmek” için kullanılır.

Başlamadan önce iş süreci analizi kontrol listesi

Özel yazılım projesine başlamadan önce aşağıdaki kontrol listesi kullanılabilir:

• Sürecin başlangıç ve bitiş noktası belli mi?
• Sürece dahil olan tüm aktörler yazıldı mı?
• Mevcut süreç gerçek haliyle haritalandı mı?
• Manuel tekrar işler ve bekleme noktaları bulundu mu?
• Hangi verinin nerede oluştuğu ve nerede kullanıldığı yazıldı mı?
• İstisna, iptal, hata ve geri dönüş senaryoları çıkarıldı mı?
• Hedef süreç mevcut süreci sadeleştiriyor mu?
• Entegrasyon ihtiyacı ve veri kaynağı belirlendi mi?
• İlk faz ve sonraki faz ayrımı yapıldı mı?
• Başarı kriteri ve ölçüm yöntemi net mi?

Sonuç: İyi analiz, yazılım riskini azaltır

İş süreci analizi, özel yazılım projesinin temelini oluşturur. Ekranlar, modüller ve entegrasyonlar analizden sonra daha doğru şekillenir. Mevcut süreç, hedef süreç, aktörler, veri akışı, istisnalar ve öncelikler netleştiğinde proje hem müşteri hem yazılım ekibi için daha öngörülebilir hale gelir.

Webioo, özel yazılım projelerinde iş süreci analizini projenin başlangıç adımı olarak ele alır. Böylece yazılım yalnızca talep edilen ekranları değil, işletmenin gerçek operasyon ihtiyacını karşılayan sürdürülebilir bir çözüm olarak tasarlanır.