Bu yazı onay bekleyen bir taslak. Metin hâlâ değişebilir; arama motorlarından şimdilik dizine eklememeleri isteniyor.
Bir onay sürecini dijitalleştirmek ancak kurum önce her adımın sahibini, eksiksiz bir talebin neye benzediğini ve biri işlem yapmadığında ne olacağını netleştirdiyse işe yarar. Yazılım bu kararları görünür ve tekrarlanabilir kılar; ama sizin yerinize vermez.
Kısa cevap
Bir şirket iç taleplerini kâğıttan, e-postadan ve Excel tablolarından bir iş akışı platformuna taşıdığında, zor olan kısım nadiren yazılımdır. Zor olan; her adımın sahibinde, bir talebin ilerleyebilmesi için hangi bilgilere ihtiyaç duyduğunda ve takılan bir talebe ne olacağında anlaşmaktır. Bu sorular netleşmezse yeni sistem eski karmaşayı yalnızca daha hızlı yeniden üretir.
Neden önemli
Çoğu kurumda kendiliğinden oluşmuş onlarca iç süreç vardır: satın alma talepleri, izin onayları, belge imzaları, ekipman talepleri. Bunlar basılı formlarda, e-posta zincirlerinde ve Excel dosyalarında yaşar. Belirtiler tanıdıktır: Talepler birinin masasında bekler, kimse bir talebin nerede olduğunu söyleyemez, iki birim aynı şeyi farklı biçimlerde onaylar.
Bunu bir araç eksikliği olarak görmek cazip gelir: Bir BPM platformu alırsınız ya da geliştirirsiniz, akışları çizersiniz ve gecikmeler ortadan kalkar. Deneyimime göre araç gereklidir, ama ikinci adımdır.
Argüman
Bir iş akışı kararları kodlar. Süreç diyagramındaki her kutu, birinin vermesi gereken bir kararı temsil eder: Kim onaylar, hangi sırayla, hangi alanlara bakarak ve ne kadar sürede. Kâğıt üzerinde bu kararlar belirsiz kalabilir, çünkü insanlar etrafından dolaşır. Memur hangi yöneticiyi arayacağını bilir; bir e-posta, doğru kişi gibi görünen birine iletilir.
Dijital bir iş akışı bu esnekliği ortadan kaldırır. Her adım için adı konmuş bir rol, her dallanma için bir kural ve istisnalar için tanımlı bir yol ister. İşe yaramasının nedeni de tam olarak budur: Süreci izlenebilir ve tutarlı kılar. Ama aynı zamanda çözülmemiş her yönetim sorusunun, takılan bir talep ya da bir tasarım tartışması olarak yüzeye çıkması anlamına gelir.
Dolayısıyla bir iş akışı projesinin ilk çıktısı bir ekran değildir. Sürecin üzerinde uzlaşılmış bir tarifidir: sahibi, adımları, kuralları ve eskalasyon yolu. Yazılım ise bu uzlaşmayı tekrarlanabilir hâle getirir.
Pratikte nasıl görünüyor
Çalıştığım dönemde bir ekiple birlikte üzerinde çalıştığım iş süreçleri yönetimi platformunda amaç, kâğıt, e-posta ve Excel ile yürüyen talepleri web ve mobilde dijital formlar, onay akışları ve görev takibiyle değiştirmekti.
Bu tür çalışmalarda üç örüntü sıkça ortaya çıkar:
- Tek seferlik geliştirme yerine parametreler. Platformu her süreç için yeniden kodlamak yerine yapılandırılabilir tasarlamak, ancak birimler roller, onay seviyeleri ve talep türleri gibi ortak yapı taşlarında anlaştığında işe yarar.
- Formlar eksik kuralları ortaya çıkarır. Kâğıt bir formu dijitale çevirmek, hangi alanların hiç kontrol edilmediğini ve hangi onayların tek bir kişinin takdirine bağlı olduğunu çabucak gösterir.
- İzlenebilirlik konuşmayı değiştirir. Her talebin durumu görünür olunca tartışmalar “nerede kaldı?” sorusundan “bu adım neden var?” sorusuna kayar; bu da bir yönetim sorusudur.
Çekinceler
Bu, yazılıma karşı bir argüman değil. Platform olmadan en iyi tasarlanmış süreçler bile izlemesi zor ve kolayca atlanabilir kalır. Bir şey geliştirmeden önce uzun analiz yapılması gerektiğini de söylemiyorum. Küçük ama gerçek iş akışları, kararların nerede eksik olduğunu keşfetmenin çoğu zaman en hızlı yoludur.
Mesele sıralama ve sahiplikle ilgili. Süreç sahipliğini bir arka plan bilgisi olarak değil, kapsamın bir parçası olarak ele alın.
İlgili içerikler
- Vaka çalışması: İş Süreçleri Yönetimi Platformu
- Hizmet: İş süreçleri otomasyonu
