Biraz iddialı bir başlık oldu biliyorum. “Süreç tasarımı ne zamandan beri şirketin en önemli işi sayılıyor?” diyebilirsiniz. Katılmam. Ne yaptığını bilen bir şirket para kazanır ancak. Bunun için de ne yapacağını ve nasıl yapacağını baştan iyi tasarlamış olması gerekir. En önemli iştir yani. Ayrıca “bizim şirkette süreç tasarımcıları var, bir odada oturup sadece süreç tasarlıyorlar” da diyebilirsiniz. Buna da inanmam! Superman veya Noel Baba kadar gerçektir o kadro, mutlaka başka işler de yapıyorlardır. Proje yöneticisi, proje ekibi, fonksiyonel yönetici, yazılım yöneticisi veya analisttir onlar; başka bir ürün çıkartırken ek iş olarak süreç tasarlamaları da gerekiyordur.

Süreç tasarımı denilince bugüne kadar iş ortamında maruz kaldığınız durumlardan dolayı muhtemelen şu iki alandan biri geliyordur aklınıza: yazılım mühendisliği ya da proje yönetimi. Ya da ikisi birden… Öyle değil mi?

Evet, önce proje yönetimine bakalım. PMI’ın PMBOK’ında proje yönetim süreçlerinin arasında “process improvement” da geçer, daha doğrusu açıkça yazmaz ama üstü kapalı biçimde ima edilir. Her şeyi kayıt altına al, zamandan kazanmak veya performansı artırmak için önerilerini paylaş, son olarak da “lessons learned” dokümanları oluştur denilir. Bunların tamamı aslında “şirketteki iş yapış şekillerini herhangi bir yönde geliştiriyorsan, bunu kayıt altına al ve şirkete kalıcı olarak kazandır, proje bitimi ile birlkte kaybolup gitmesin” demektir.

Rita Mulcahy (RIP) ise kitabında bunu açık açık söyler. Planlama süreçleri arasında “process improvement” için bir planın olsun der (create process improvement plan) ve yürütme süreçleri arasında da sürekli olarak gelişimi sağla der (continuously improve). Rahmetli Rita (Hristiyanlara “rahmetli” denmez belki ama mekanı cennet olsun) PMP sertifikasyon sınavlarına hazırlık için yıllardır yazdığı kitaplarda PMBOK’ın temel mantığını anlatmaya ve farklı yoldan öğretmeye çalışırdı zaten.

Özetle, bir yandan projeyi yönetir ya da yürütürken diğer yandan teoride şirket için süreç iyileştirmesi yapar, bir işin daha iyi bir yapılış şekli varsa bunu kayıt altına alır ve sistemleştirirsiniz. Böylece proje yürüten birim aslında şirketin süreçlerinin iyileştirilmesine de yardımcı olur.

Yazılım tarafına gelecek olursak süreç tasarımı daha da önem kazanır. Zaten yazılım ile çözülecek ihtiyacın analizini yapmadan kod yazmaya başlayamazsınız. Bu analiz yapılırken tasarıma da ister istemez girilir. Analiz ve tasarım çoğu yazılım projesinde birbirinden ayrılamayacak kadar içiçe giren kavramlardır. Yazılım işindeki bir yönetici aynı zamanda müşteri ihtiyacını net olarak anlayabilecek kadar iyi bir analist olmak, süreç tasarımına aşina olmak durumundadır.

İşte bu noktada süreç tasarımı kavramının ne olduğunu daha net anlatabilmek için düşüncelerinizi bu iki alandan bağımsızlaştırmak istiyorum. Süreç tasarımının bir proje süreci içinde yan ürün olarak yapılmadığı ya da süreç tasarımı sonucunda bir yazılımın geliştirilmeyeceğini düşünün lütfen. Eminim zor olacak, çünkü en başta dediğim gibi bugünün şirketlerinde doğrudan süreç tasarımcısı kadrosu diye bir kadroya rastlamanız pek mümkün değil.

Örneği somutlaştırmak için bir miktar zaman yolculuğu yapıp 20-25 yıl kadar önceye gidelim. Bilgisayar kullanımının çok yaygın olmadığı, işleri daha ziyade kağıtlar ve formlar üzerinde yaptığımız yıllara. O dönemde faaliyet gösteren bir tekstil şirketinin satın alma sürecinde iletişimsizlikten doğan zaman ve para kaybı yaşadığını, genel müdürün sizi ve ekibinizi bu işi çözmek için görevlendirdiğini düşünün. Mesela 20 top kumaş geliyor depoya ve depo yetkilisi “biz böyle bir sipariş vermedik, yanlış sevkiyat, belki yandaki fabrikaya gelmiştir” diyerek kamyonu geri yolluyor. Bu olaydan birkaç saat veya bir iki gün sonra planlama müdürü depoyu arayıp “hala gelmedi mi kumaşlar?” diyor.

Eminim çok tuhaf geliyordur size şu anda ama inanın böyle şeyler olabiliyordu. “Burada hata nerede yapılıyor? Neden böyle bir koordinasyonsuzluk oldu?” sorusunun cevabını verebilmeniz için öncelikle süreç tasarımının “analiz” aşamasını yapmak durumundasınız. Buna mevcut durum analizi, AS-IS diyoruz. Hemen sonrasında da bu hatanın bir daha tekrarlanmamasını sağlayacak bir “tasarım”, yani TO-BE ile genel müdürünüzün karşısına çıkmanız, istenen durumu şema üzerinde özetleyebilmeniz gerekir.

Bu analiz ve tasarım çalışmalarını yaparken çok kritik sorular sizi bekler. Bunları hem kendinize, hem sürecin sahiplerine, yani o birimde çalışanlara, hem de tepe yöneticilere sormanız gerekir. Bu iş gerçekten gerekli mi? Bu işi yapmak bize ne fayda sağlıyor? Yapmasak ne kaybederiz? Mutlaka yapılması gerekiyorsa daha kolay bir yapma şekli var mıdır? En çok zaman alan kısımları hangileridir? Bu işi outsource edebilir miyiz, edersek ve etmemişken maliyetleri bize ne kadara geliyor? Bu işin girdileri nelerdir, çıktıları nelerdir? Çıktıların her biri nerede kullanılıyor? Öyle ya, belki üretmek için saatlerinizi harcadığınız o raporu kimse okumuyordur?!…

Yukarıdaki bir soru son derece kritik aslında: Bu işi yapmasak ne kaybederiz?

Şirketlerde “burada işler böyle yapılır” adlı bir sendrom vardır. Aslında şirket kültürünü, felsefesini işaret eder ve normalde sendrom değildir. Bu kavram eğer iş yapma şeklini sabitleyen, yıllarca sorgulanmayan bir hale gelirse, yani “The way we do things around here” cümlesi peşinden “and the way we will always do it around here” cümlesini getiriyorsa sendrom halini alır. Şirket kültürü olan halini savunan kaynaklar var, ama ben ona da karşıyım. Çünkü bunun ne zaman kemikleşmiş olduğunu bir süre sonra ayırt edemezsiniz ve sabitleşmiş hali çok fenadır. Çalışanlar kendilerine söylenen işi kayıtsız şartsız yapar ve şirkete faydasını hiç sorgulamaz. Patronlar da mutludur çünkü bir grup itaatkar çalışan kuzu gibi çalışmaktadır, daha ne olsun? Halbuki babadan kalma o iş şekli belki artık örgütün değişmiş olan dinamiklerine hiçbir şey katmıyordur? Çalışan sorgulamaz, patron da onu “tanım gereği” bir iş olarak kabullenmiştir yıllardır ve faydasını sorgulamak aklına bile gelmez. Harry Frederick Harlow’a ait olduğu rivayet edilen meşhur 5 maymun deneyindeki gibi… İşte bu noktada, atılan taşın ürkütülen kurbağaya değip değmediğini sorgulamak kahraman süreç tasarımcısının işidir.

Zaman tünelinde biraz daha günümüze yaklaşalım. Süreçlerin mümkün olan en düzgün şekilde tasarlandığı zamanlarda da şirketler için basma kalıp şekilde üretilmiş olan yazılımlarla entegrasyon krizleri yaşadı Türkiye. Süreç tasarımının yazılımdan bağımsız bir beceri olduğunu biliyorsunuz artık. Diyelim şirketiniz için en doğru akışları oluşturdunuz ve bu akışlar üretimde bantlar veya iş istasyonları olmasını gerektiriyor. Size gelen yazılımcıların, size sunduğu ERP paketinin içinde bu tür bir (customization) kişiselleştirme yapılamıyorsa almayın o paketi daha iyi. Bu sefer sizin için en doğru iş yapma şeklini bildiğiniz halde bunu hayata geçirme şansınızı ortadan kaldırıyor ve groupware’in size sunduğu kadar beceri ile işlerinizi yönetmeye çalışıyorsunuz. Bu da çok büyük hata! Senelerce birçok şirket yaşadı bunu Türkiye’de, neyse ki son yıllarda yazılım sektörü inanılmaz gelişti. Büyüklerin kendi yazılım ekipleri var. Yazılım üreten firmalar da müşteri ihtiyacına göre terzi işi ürünler çıkartabiliyor.

Süreç tasarımcısının eski zamanlardan beri kağıt bir form ile, basit bir bilgilendirme ekranı ile, ya da 5 madde içeren, uygulanması son derece kolay bir prosedür ile hangi dertlerin önüne geçebileceğine inanamazsınız. Bu, süreç tasarımcılarının olağanüstü insanlar olmasından kaynaklanmaz, çok basit anlamda “biz bu hatayı neden yaptık, bir daha olmasını nasıl engelleriz?”diye konu hakkında kafa patlatmasından kaynaklanır. Şirkette birileri işleyişte iyileştirmeler yapmak için yetkili kılınmalı ve onaylanan öneriler cesaretle hayata geçirilmelidir. Aksi takdirde 10 yıl sonra neden iflasın eşiğine geldiğinizi arar durursunuz.

Artık her şey daha kolay. İyi tasarlanmış bir süreç anında elektronik olarak dolaşıma girecek bir form ya da farklı bir yazılım haline getirilebiliyor. Şirketler kısa zamanda çok iş bitirebiliyor, hepsini mümkün olan en verimli şekilde yapabiliyor. Herkes mutlu artık. Sadece süreç tasarımını içselleştirmiş kişiler işleri gereği mutsuz. Onlar sürekli “bu işi daha iyi nasıl yaparız?” ya da “bu işi yapmamız gerçekten gerekli mi?” diye kendilerine soruyor. Her yapılan işte bunu araştırıyor ve şirkette paranoyanın sınırlarında dolaşıyor :). Yine de süreç tasarımı şirkete kazandırdıkça bu mutsuzluğun çok daha üzerinde bir manevi tatmin ile ödüllendirebiliyorlar kendilerini. Her şeye değer…

 

Baler Eskibatman, PMP