İş Akışı mı, Süreç mi? Workflow ile Process Arasındaki Fark

Kısa yanıt: biri sonucu, diğeri yolu tanımlar

Süreç, bir kurumun belirli bir sonucu üretmek için yürüttüğü faaliyetlerin uçtan uca zinciridir. Müşteri siparişinin teslim edilmesi, yeni bir çalışanın işe başlaması ya da bir şikâyetin çözülmesi birer süreçtir. Süreç birden fazla birimi kesebilir, bir sahibi ve ölçülen bir sonucu vardır.

İş akışı ise bu zincirin içinde işin nasıl yürüdüğünü tanımlar: hangi görev kimde, hangi sırayla, hangi koşulda bir sonraki adıma geçilir, onay nerede verilir. İş akışı çoğu zaman tek bir ekip ya da tek bir yazılım içinde tanımlanır ve kurallarla işletilir.

Bu yüzden iki kavram birbirinin rakibi değil, farklı düzeylerin adıdır. Süreç "ne ve neden" sorusuna, iş akışı "kim, hangi sırayla ve nasıl" sorusuna yanıt verir. Aynı süreç farklı akışlarla yürütülebilir; örneğin bir şube onayı e-postayla, diğeri bir yazılımla alırken ikisi de aynı sürecin parçasıdır.

Ölçüt ölçüt iş akışı ve süreç

Kapsam: İş akışı sürecin bir bölümünü, belirli bir görev dizisini kapsar. / Süreç girdiden müşteriye ulaşan çıktıya kadar uçtan uca zinciri kapsar.

Odak: İş akışı sıraya, kurala, onaya ve devre odaklanır. / Süreç sonuca, değere ve müşteri deneyimine odaklanır.

Sınırlar: İş akışı çoğunlukla bir ekip ya da tek bir sistem içinde kalır. / Süreç sıklıkla birden fazla birimi ve sistemi keser.

Sahiplik: İş akışının sahibi genellikle ilgili ekip lideri ya da akışı yöneten sistemin sorumlusudur. / Sürecin sahibi uçtan uca sonuçtan sorumlu bir yöneticidir.

Ölçüm: İş akışında adım bekleme süresi, onay sayısı ve geri dönen iş izlenir. / Süreçte uçtan uca süre, maliyet, kalite ve müşteri memnuniyeti izlenir.

Gösterim: İş akışı akış şemasıyla ya da iş akışı aracındaki tasarımla gösterilir. / Süreç süreç haritası, değer akışı ya da BPMN gibi gösterimlerle ele alınır.

Değişim sıklığı: İş akışı kural ya da sistem değiştikçe sık güncellenir. / Süreç daha seyrek, strateji ya da müşteri beklentisi değiştiğinde yeniden tasarlanır.

Bir müşteri iadesi örneğinde süreç ve iş akışları

Bir e-ticaret şirketinin müşteri iadesi sürecini düşünelim. Süreç, müşterinin iade talebini iletmesiyle başlar ve parasının hesabına geçmesiyle biter. Sürecin sahibi müşteri deneyiminden sorumlu bir yöneticidir; izlediği şey, talepten paranın iadesine kadar geçen süre ve müşterinin memnuniyetidir.

Bu sürecin içinde birbirinden ayrı iş akışları çalışır. Müşteri hizmetlerinde iade talebinin uygunluğu kontrol edilir ve gerekiyorsa bir yöneticinin onayına gider. Depoda gelen ürün teslim alınır, durumu kontrol edilir ve stoka ya da hurdaya ayrılır. Finansta onaylanan iade için ödeme talimatı oluşturulur ve muhasebeleştirilir. Her akışın kendi kuralı, sorumlusu ve çoğu zaman kendi yazılımı vardır.

En alt düzeyde ise tek tek görevler bulunur: bir temsilcinin talebi incelemesi, bir depo çalışanının paketi açması. Görevler akışları, akışlar da süreci oluşturur.

İş akışını otomatikleştirmek süreci iyileştirir mi?

Her zaman değil. İade örneğinde müşteri hizmetlerindeki onay akışı otomatikleştirildiğinde talepler artık beklemeden onaylanır. Ancak depo kabulü elle ve haftada belirli günlerde yapılıyorsa, onaylanan iadeler depoda birikir; müşteri yine parasını geç alır. Bir akış hızlanmış, süreç sonucu değişmemiştir.

Bu durum, iyileştirmenin yerel bir akışta değil sürecin bütününde ölçülmesi gerektiğini gösterir. Bir iş akışını otomatikleştirmeden önce şu sorular sorulmalıdır: Bu akış sürecin darboğazı mı? Akış hızlandığında iş bir sonraki adımda birikecek mi? Akışın ürettiği çıktı, sürecin bir sonraki adımının ihtiyacına uyuyor mu?

Bir başka risk, kötü tasarlanmış bir süreci olduğu gibi otomatikleştirmektir. Gereksiz bir onay adımı yazılıma taşındığında ortadan kalkmaz, yalnızca daha hızlı tekrarlanır. Bu yüzden otomasyon projesinden önce sürecin sadeleştirilmesi, otomasyonun kendisinden daha büyük kazanç getirebilir.

İyileştirme hangi düzeyde yapılmalı?

Sorunun belirtisi, çözümün hangi düzeyde aranacağını gösterir. Müşteri yanlış ya da eksik sonuç alıyorsa, birimler birbirinden habersiz çalışıyorsa veya kimse sonuçtan sorumlu görünmüyorsa sorun süreç düzeyindedir; süreç yeniden tasarlanmalı ve bir süreç sahibi atanmalıdır.

Sonuç doğru ama yavaşsa, iş onay bekleyerek ya da kişiden kişiye geçerken kayboluyorsa sorun iş akışı düzeyindedir; akışın kuralları sadeleştirilir, devirler netleştirilir ve gerekiyorsa otomasyon eklenir.

Aynı adım her çalışan tarafından farklı yapılıyorsa sorun ne süreçte ne akıştadır; adımın kendisi için yazılı bir prosedür ya da talimat gerekir.

Belgelerde ve araçlarda iki kavramı karıştırmamak

Kavram karışıklığı en çok belgelerde ve araç seçiminde maliyet yaratır. Sık görülen hatalar şunlardır:

• Bir iş akışı aracında tasarlanan onay zincirini "süreç tasarımı" saymak ve uçtan uca sonucu hiç ölçmemek
• Süreç haritasını görev ve onay ayrıntısıyla doldurup okunamaz hâle getirmek
• Her birimin kendi akışını iyileştirmesini, sürecin iyileşmesi sanmak
• Süreç sahibi ile akışı yöneten sistem sorumlusunu aynı rol olarak görmek

Pratik bir kural işe yarar: süreç belgesi bir sayfada sürecin amacını, sınırlarını, sahibini, ana adımlarını ve ölçülerini göstermelidir. İş akışı tanımı ise o adımlardan birinin içinde kimin neyi hangi koşulda yaptığını ayrıntılandırır. İki belge birbirine bağlantılıdır ama birbirinin yerine geçmez.

Mindset programlarında süreç ve iş akışı

Süreç sahipleri, kalite ve operasyon ekipleri için İş Süreç Yönetimi Eğitim Programı; süreç analizi ve modelleme, süreç tasarımı ve optimizasyon, değişim yönetimi ve süreç sahipliği ile süreç izleme ve iyileştirme başlıklarında uçtan uca bakışı kurar ve bir final projeyle uygular. İş akışının sürecin içindeki yerini görmek, bu programın modelleme ve tasarım bölümlerinin doğal parçasıdır.

Onay zincirlerini ve görev akışlarını tasarlayan ekipler İş Akışı Tasarımı ve Onay Süreçleri eğitimine, süreçleri ortak bir gösterimle çizmek isteyenler Süreç Modelleme (BPMN) eğitimine bakabilir.