İş akışı nedir: bir kayıt hangi durumlardan, kimin eliyle geçer

İş akışı, bir işin kaydının sırayla geçtiği durumlar ve o durumlar arasındaki geçişlerdir. İşletmede ne işe yaradığı da buradan çıkıyor: kayda bakan kişi işin şu an nerede durduğunu ve onu kimin ilerletebileceğini görüyor. Diotek’in sitesinden açılan talep yazılı bir kayıt olarak kalıyor; hat meşgulken gelen talep de kayıtsız kalmıyor.

İş akışı nedir: bir kaydın hangi durumda olduğunu gösteren dizi

Akışın parçalarını adlandırmadan tanımı kurmak zor. Ortada işin kaydı var: siparişin, talebin, randevunun ya da iş emrinin kendisi. Kaydın üstünde o an bulunduğu durum duruyor. Durumdan duruma gidiş bir geçiş. Geçişi yapma hakkı tanımlanmış bir taraf var. Bir de akışın kapandığı hâlin tanımı var. Bu parçalar bir araya geldiğinde elde kalan şey bir resim değil, kaydın üstünde okunabilen bir sıra oluyor.

Sade bir örnek, işletme sahibinin diliyle: bir talep açılıyor, birine düşüyor, cevap bekliyor, kapanıyor. Bu dizinin adı iş akışı. Her adım bir durum, adımlar arasındaki her hareket bir geçiş. Örnekteki hiçbir adım kendiliğinden gelmiyor; her birini ya biri yapıyor ya da olup bitmiş bir şey tetikliyor.

Durumun nerede yaşadığı yazının geri kalanını belirliyor. Durum, kaydın üzerinde duran bir bilgi: kaydı açan kişi aynı anda onun nerede olduğunu da okuyor. Ayrı bir tabloda, bir mesaj dizisinde ya da birinin ajandasında tutulan durum kayıtla birlikte dolaşmıyor; kaydı açan kişiye görünmüyor.

Geçişin kendiliğinden olmadığını baştan söylemek gerekiyor. Bir kayıt bekleme hâlinden onaylanmış hâle kendi kendine geçmiyor; o geçişi birinin ya da bir şeyin yapması gerekiyor. Sahibin kim olabileceği ayrı bir bölümün konusu. Burada yalnız her geçişin bir sahibi olduğu kaydediliyor.

Bu soru başka bir sorunun hemen yanında duruyor. Bir kaydın kaç ayrı programa dokunduğunu saydığımız yazı, yetki ve onay tarafını kapsamının dışında bıraktı ve bunu açıkça yazdı. Buradaki konu o kapının arkası: kaydın kaç programa dokunduğu değil, hangi durumlardan ve kimin eliyle geçtiği.

Akış şeması akışın resmi; akışın kendisi kayıtta duruyor

İş akışı sorusunun bir kısmı şema arıyor: kutular, oklar, bir de sembol cetveli. Şema gerçek bir iş görüyor ve bu yazı onu reddetmiyor. İş akışı şeması, akışı anlatmak için çizilen bir resim. Resmin anlattığı şeyle resmin kendisi ayrı şeyler ve ayrım tam burada başlıyor.

Çizimin taşıyamadığı şeyler var. Belirli bir kaydın şu an hangi durumda olduğunu çizim söylemiyor; çizim bütün kayıtlar için aynı duruyor. Bir geçişi kimin yapabileceğini de söylemiyor; okun üstüne bir rol adı yazılsa bile o ad bir yetki kuralı değil, bir not. İkisinin de yazılımda bir yere kaydedilmesi gerekiyor.

Çizim ile kayıt ayrı yerlerde yaşıyor ve bunun pratik bir sonucu var: biri değişince öteki haber almıyor. Duvardaki şema güncellendiğinde ekrandaki durum alanı değişmiyor. Yazılımdaki durum listesine yeni bir hâl eklendiğinde de duvardaki şema bayatlıyor, çoğu zaman kimse fark etmiyor. Birbirini güncellemeyen yüzeylerden güvenilecek olan kayıt oluyor.

Çizimin işe yaradığı yeri de yazalım. Akışı ilk kez konuşurken masadaki herkese ortak bir dil kuruyor; hangi adımdan sonra ne geliyor sorusu orada görünür hâle geliyor. Ama anlatma işi bittiğinde kayıt tarafı hâlâ kurulmamış oluyor. Çizim anlatmak için iyi, izlemek için yetersiz.

Bu yüzden iş akışını sisteme dökme isteği pratikte şu sorulara iniyor: hangi durumlar olacak ve her geçişi kim yapacak. Yazının geri kalanı bu sorulara göre diziliyor.

Akış nerede başlar, nerede biter

Bir akışı tanımlamanın ilk adımı onun hangi kaydın akışı olduğunu söylemek. Akış işin değil kaydın akışı. Ayrım kulağa ince geliyor ama akışı adlandıran şey kayıt birimi oluyor. Klima işinde birim keşif randevusu ya da servis talebi; pilates salonunda rezervasyon; tahlil yorumlamada hastaya gidecek metin. Birim adlandırılmadan durum listesi yazılamıyor, çünkü hangi şeyin durumunu izlediğiniz belli olmuyor.

Başlangıç, kaydın doğduğu an. Bitiş, kaydın bir daha ilerlemeyeceği hâl. İkisi de bir tarih değil bir hâl olarak tanımlanıyor ve bunun pratik bir karşılığı var: aynı akış farklı işlerde farklı sürelerde kapanıyor, kapanışı takvim belirlemiyor.

Sınır çizilmediğinde durum listesinin bozulma biçimi tek değil. Liste bazen işin yapılmadığı yerlere doğru uzuyor: kaydın hiç dokunulmadığı aşamalar için durumlar açılıyor ve onları kimse güncellemiyor. Bazen de işin fiilen bittiği yerde eksik kalıyor: kapanış hiçbir yere yazılmıyor, kayıt son durumunda süresiz bekliyor. Uzayan liste gürültü üretiyor; eksik kalan liste hiç kapanmayan bir kuyruk üretiyor.

Bir kaydın akışı başka bir kaydın akışını tetikleyebiliyor. Keşif randevusu kapandığında bir teklif kaydı doğabiliyor; teklif kabul edildiğinde bir iş emri doğabiliyor. Bunlar tek bir liste değil, birbirine bağlanmış ayrı listeler. Hepsini tek durum listesine sığdırmak, az önce yazılan hataların her birini aynı anda üretiyor.

Sınırı çizmek yazılım işi de değil. Kaydın hangi hâlden sonra bir daha ilerlemeyeceğini ancak o işi yapan biliyor; yazılım bu kararı soruyor, vermiyor. Soru sorulmadan kurulan listeler yazılımcının tahminini taşıyor ve kullanımda düzeltilmesi gerekiyor.

Durum alanının kaydın neresinde duracağı ve kaydın neye bağlanacağı ayrı bir işin konusu. Kaydın neye bağlanacağına ve verinin hangi sınırda duracağına karar verilen yer burası değil; o karar bir veri modeli kararı. Bu yazı kararı vermiyor, yalnız akışın sınırının onunla birlikte çizildiğini söylüyor.

Durum bir yere yazılı değilse akış her sabah yeniden kuruluyor

Bir akışın yazılı olup olmadığını anlamanın yolu tek bir soruyu sormaktan geçiyor: bu iş şu an nerede sorusunun cevabı kaydın kendisinden okunuyor mu, yoksa birine sorulmak zorunda mı. Cevap kayıttan okunuyorsa akış yazılı. Birine soruluyorsa akış kafalarda duruyor ve her sabah yeniden kuruluyor.

Talebin siteden açılıp yazılı kayıt olarak kaldığı klima ve havalandırma sitesinde çıkış durumundaki sorunlardan biri şuydu: telefon hattı meşgulken arayan ziyaretçi kayboluyordu, site de bu akışın dışında duruyordu. Bugün aynı talep siteden açılıyor ve yazılı kalıyor.

Yazılı olmanın ilk şartı, durumun kaydın kendi alanında durması. Kayıttan ayrı bir yerde tutulan durum kayıtla birlikte dolaşmıyor: kaydı açan kişi onu görmüyor, görmek için ikinci bir yere bakması gerekiyor. O ikinci yer bir çalışma tablosu, bir mesaj dizisi ya da birinin not defteri olabilir. Hepsinde durum var, ama kayıtta yok.

Akış yazılı değilken de işler yürüyor; bunu kabul etmek gerekiyor. Yürümesini sağlayan şey yazılım değil, akışı hatırlayan kişi. O kişi hangi talebin kimde beklediğini biliyor, kimin neyi onaylayacağını biliyor, sırayı da biliyor. Bilginin tamamı doğru ve tamamı tek bir yerde: onun hafızasında. O kişi izne çıktığında akış da izne çıkıyor; geriye kimsenin okuyamadığı bir kayıt yığını kalıyor.

Sınamanın işe yarayan tarafı yazılım almadan önce yapılabilmesi. Kendi işinizde bekleyen bir kayda bakmak yeterli: nerede olduğunu kayıt söylüyorsa sorunuz başka bir yerde duruyor. Söylemiyorsa durum alanı kurmak, yeni bir ekran eklemekten önce gelen iş oluyor.

Her geçişin bir sahibi var: kişi, rol, olay ya da dışarıdaki taraf

Akışta her geçişin bir sahibi var: o geçişi yapma hakkı olan taraf. Sahip yazılı olmadığında geçiş kendiliğinden oluyormuş gibi görünüyor, oysa onu her seferinde biri yapıyor. Yazılı olmaması geçişi ortadan kaldırmıyor, yalnız görünmez kılıyor. Sahibin cinsi de tek değil ve hangi cins olduğu işin yazılımdan ne isteyeceğini belirliyor.

Sahip, adı ve yetkisi belli bir kişi olabiliyor. Hastaya ulaşan yorumun hekim onayından çıktığı platformda yorumu panelde yazıp onaylayan taraf hekim. Onay adımının akışın neresine konduğunu ön okuma ile onaylanmış hâl arasındaki ayrımı açtığımız yazıda ele aldık.

Sahip bir rol olabiliyor. Aynı ders programı kaydına her tarafın kendi yetkisi kadar eriştiği platformda kaydı öğretmen de açıyor, veli de, kurum yöneticisi de; her biri yetkisinin izin verdiği kadarını görüyor. Rolün farkı şu: geçişi yapan kişi değiştiğinde hak yerinde kalıyor. Aynı kayda rolüne göre bakmanın nasıl kurulduğunu ayrı bir yazıda açtık; burada rol yalnız geçişin sahibi olarak duruyor.

Sahip bir olay olabiliyor: geçişi bir kişinin kararı değil, kuralda tanımlı bir hâlin oluşması taşıyor. Bekleme süresinin dolması böyle bir hâl. Pilatesco’da gelmeme hâli bakiyeye kuralda tanımlı biçimde işliyor; hangi hâlin hakkı geri vereceğini kural söylüyor.

Sahip işletmenin dışındaki taraf olabiliyor. Diotek’te akışın ilk geçişini ziyaretçi yapıyor: keşif randevusunu ya da servis talebini kendisi açıyor. Dışarıdaki taraf yalnız yetki istemeyen geçişleri yapabildiği için dışarıya açılan geçişin hangi durumda bittiği baştan tanımlanıyor. Kayıt, içeride birinin devralacağı bir hâlde doğuyor.

Cevapları yan yana koymak işe yarıyor. Tablonun ekseni proje listesi değil sahibin cinsi: her satırda geçişi başlatan şey, kayıtta kalan iz ve bunun nerede böyle kurulu olduğu duruyor.

Tabloyu okuma yönü satırlar. Her satır, geçişin sahibi değiştiğinde yazılıma düşen işin de değiştiğini gösteriyor: kişi sahipse onayın kayda geçmesi, rol sahipse hakkın role bağlanması, olay sahipse kuralın kendisi, dışarıdaki taraf sahipse geçişin nerede durduğu.

Karşı durum şurada: sahibi olmayan geçiş yok, ama sahibi yazılı olmayan geçiş çok. O hâlde hakkı olan tarafı her seferinde ortam belirliyor: kim müsaitse, kim hatırlıyorsa, kim o sırada ekranın başındaysa. Akış aynı görünüyor, sahibi her seferinde değişiyor. Yazılmamış sahiplik bir boşluk değil, dolduran kişiyle birlikte değişen bir kural.

Bir geçiş kaydın dışında da bir şeyi değiştirebiliyor

Bazı geçişler yalnız durumu ilerletmiyor, ikinci bir kaydı da hareket ettiriyor. Durum listesi bu etkiyi tek başına göstermiyor: listede yazan şey kaydın nerede olduğu, ikinci etki ise başka bir kaydın neye dönüştüğü.

Rezervasyonun paket bakiyesinden ders hakkı düşürdüğü randevu sisteminde bu etki kuralda yaşıyor: bir rezervasyon takvime işlendiği anda müşterinin paketinden ders hakkı eksiliyor ve bakiye müşterinin kendi kaydının üstünde duruyor. Rezervasyonun bakiyeyi hangi kurala göre hareket ettirdiğini talep tiplerinin ayrı akışlar olarak kurulmasını anlattığımız yazıda açtık. Burada bizi ilgilendiren şey ikinci etkinin nerede tanımlı olduğu.

İkinci etkisi yazılmamış bir geçiş akışın en pahalı yerinde yakalanıyor. Durum ilerlemiş görünüyor, ona bağlı hak ya da bakiye ilerlememiş oluyor. Yakalanma anı da gecikmeli: fark kaydın kendisine bakıldığında değil, bakiye sorulduğunda ortaya çıkıyor. O noktada hangi geçişin hangi hareketi üretmesi gerektiği yeniden konuşuluyor ve konuşmanın sonucu kurala değil o günün kararına yazılıyor.

Etkinin yazıldığı yer de önemli. İkinci hareket bir ekranın arkasına değil geçişin kuralına bağlandığında, kaydı kim ilerletirse ilerletsin aynı hareket doğuyor. Ekrana bağlı kalan hareket ise yalnız o ekranı kullananlar için işliyor.

Bu yüzden akışı yazıya dökerken her geçişin yanına ikinci bir soru da yazılıyor: bu geçiş durumdan başka neyi değiştiriyor. Soruyu geçiş başına sormak, akışı anlatan bir çizimden bambaşka bir metin üretiyor; ortaya çıkan şey oklar değil kurallar oluyor.

Her geçiş bu soruyu hak etmiyor. Geçişin tek işi durumu ilerletmekse arkasına bir kural yazmak gereksiz bir ağırlık. Akışa bağlanması gereken şey durumun kendisi değil, duruma bağlı olarak değişen ikinci kayıt; öyle bir kayıt yoksa durum alanı tek başına yetiyor.

İnce bir durum listesi bekleyen işi adıyla gösteriyor

Durum listesinin kaç adımdan oluştuğu bir görünürlük kararı. Liste ne kadar inceyse işin nerede beklediği o kadar ince okunuyor. Açık ile kapandı arasında başka hiçbir hâl yoksa, açık duran bir kaydın kimde beklediği kayıttan okunamıyor; o bilgi yine konuşmayla taşınıyor.

İnceltmenin bedeli de var. Kimsenin güncellemediği bir durum yanlış cevap veriyor ve yanlış cevap hiç cevap vermemekten pahalı: biri ekrana bakıp işin ilerlediğini sanıyor, oysa kayıt orada bekliyor. Liste uzatmak tek başına görünürlük getirmiyor; getirdiği şey güncelleme yükü.

Ölçüt şu: bir durum ancak gerçekten birinin elinde bekleyen bir hâli adlandırıyorsa listeye giriyor. Devam ediyor gibi bir durum kimseyi adlandırmıyor, o yüzden işin nerede beklediğini de söylemiyor. Hekim onayı bekliyor adlandırıyor; müşteri cevabı bekliyor adlandırıyor. Ölçütü uygulamanın yolu listeye bakıp her satır için aynı soruyu sormak: bu hâlde kayıt kimin elinde duruyor. Tahlil.com’da ön okumadaki kayıt bu soruya hekimi gösteriyor.

Bekleme hâllerini kimin beklediğiyle adlandırmanın pratik bir karşılığı var: yapılacak iş de ona göre değişiyor. Kayıt dışarıdaki tarafı bekliyorsa yapılacak iş hatırlatma. Bir rolü bekliyorsa yapılacak iş yetkinin dağıtımı. Bir olayı bekliyorsa yapılacak iş beklemenin süresini izlemek. Hak kişiye değil role bağlandığında bekleyen kayıt belirli bir kişiyi değil o rolü bekliyor; rolü taşıyan biri izinli olduğunda aynı rolü taşıyan başka biri devralıyor.

Karşı durum da yazılsın: her hâli listeye eklemek görünürlük getirmiyor. Güncelleme işi işin kendisinden büyüdüğünde liste bayatlıyor ve kimse ona bakmıyor. O noktada ekranda duran durum gerçeği değil, son güncelleyenin hatırladığını gösteriyor.

Akışı yazılıma dökmenin gerekmediği yer ve gösterebildiğimiz sınır

Akışı yazılıma dökmek her işte kazanç değil. Geçişi aynı kişi yapıyorsa ve iş aynı oturumda kapanıyorsa durum alanı kurmak kaldırdığından büyük bir iş getiriyor: devredilen bir şey yok, bekleyen bir taraf yok, kaydı açan kişi onu kapatan kişiyle aynı.

Belirleyici olan iş hacmi değil, bir sonraki hareketi başkasının yapıp yapmadığı. Günde çok iş gören ama her işi baştan sona tek elden yürüten bir atölyede durum alanı boş kalıyor. Az iş gören ama her işte onay bekleyen bir kurumda ise liste ilk günden dolu çalışıyor. Akış, işin birinden ötekine geçtiği yerde başlıyor.

Sınırımızı da burada yazalım. Gösterebildiğimiz akışlar operasyonel kayıtların akışı: talep, randevu, iş emri, giriş kaydı ve onay. Kurumsal onay zincirleri ve bütçe akışları için gösterebileceğimiz bir iş yok. Bu bir kapsam pazarlığı değil, kanıtın bittiği yer.

Sınırı yazmak kapsamı daraltmıyor, arayışın adresini netleştiriyor. Aradığınız şey kademeli bir onay zincirinin kendisiyse bu kapsam o arayışa cevap vermiyor ve bunu ilk görüşmede duymanız işinize yarıyor.

Kapanışta tek bir iş var. Bir işin şu an kimde beklediğini kaydın kendisinden okuyamıyorsanız başlangıç noktası bir çizim değil; hangi durumların olacağı ve her geçişi kimin yapacağı. Kaydın durumunu ve geçişin sahibini izleyen hizmette başladığımız yer de burası.