SOP'u İş Akışına Çevirin: Durumlar, Kararlar, Son Tarihler

Neden yazılı bir SOP uygulamak zor olabilir

Yazılı bir SOP kağıt üzerinde net görünebilir ama günlük işte başarısız olabilir. İnsanlar meşguldür, görevler yanlış sırayla gelir ve belge genellikle ilk okumadan sonra dokunulmadan kalır.

Burası ilk sorun: süreç hafızaya bağlıdır. Birinin 4. adımı hatırlaması ya da incelemeden sonra ne olacağını tahmin etmesi gerekiyorsa, SOP artık işi yönlendirmiyor demektir. Takım yönlendiriyor.

İkinci sorun gizli kararlar. Bir SOP "talebi inceleyin" veya "onayı kontrol edin" diyebilir, ama evet, hayır veya henüz değilse ne olacağı sıklıkla atlanır. Bu seçimler genellikle en deneyimli kişinin kafasında kalır ve herkes bekler.

Son tarihler de zayıf noktadır. Pek çok SOP "mümkün olan en kısa sürede" veya "makul bir süre içinde" gibi belirsiz ifadeler kullanır. İş birikince bu ifadeler sorun çıkarır. Biri görevin bugün teslim olduğunu düşünürken diğeri Cuma uygun diye düşünebilir ve istek sessizce bekler.

Sahiplik de genellikle belirsizdir. Yazılı prosedür bölümleri belirtebilir ama bir sonraki kim hareket edecek açık olmayabilir. Handover'lar belirsizse, işler gelen kutularında ve sohbetlerde bekler çünkü kimsenin bir sonraki adıma sahip olduğu net değildir.

Uygulamada bu genellikle görevlerin başlatılıp sonra duraklaması, yöneticilerin aynı küçük soruları tekrar tekrar yanıtlaması, gerçek bir teslim tarihi belirlenmediği için son tarihlerde kaymalar ve ekip üyelerinin başkasının ilgilendiğini varsayması anlamına gelir.

Çözüm basit: tahmini ortadan kaldırın. İnsanlar mevcut durumu görebilmeli, bir sonraki kararı anlayabilmeli, son tarihi bilmeli ve kimin tam olarak harekete geçeceğini bilmelidir. Bu parçalar görünür olduğunda süreç bir belgede yaşamayı bırakır ve gerçek hayatta işler.

Herhangi bir şeye başlamadan önce SOP'yi haritalayın

Ekranlar, formlar veya otomasyonlarla başlamayın. Süreci bugün nasıl gerçekleşiyorsa sade bir dille, ilk tetikleyiciden sonuca kadar haritalayarak başlayın.

İyi bir harita bir temel soruya cevap verir: bir sonraki adımda bir kişi gerçekte ne yapar? Bir adım "talebi incele" ya da "sorunu ele al" gibi belirsizse, bir kişinin tahmin etmesine gerek kalmadan izleyebileceği bir eyleme dönüştürün.

İlk turda her eylemi basit bir fiil + nesne olarak kaydedin: "kimlik topla", "sözleşmeyi kontrol et", "bütçeyi onayla", "karşılama e-postası gönder" gibi. Bu, eksik adımları tespit etmeyi ve daha sonra bunları durumlar ve karar noktalarına çevirmeyi kolaylaştırır.

Sonra sürecin başlangıç ve bitiş sınırlarını tanımlayın. Nerede başlıyor: gönderilmiş bir form mu, yeni bir müşteri mi, yönetici talebi mi? Nerede bitiyor: onaylandı, reddedildi, gönderildi, tamamlandı, kapatıldı? Net başlangıç ve bitiş noktaları iş akışının karışmasını önler.

Her adım için gerçek bir rol atayın. "İK müdürü" "İK" den daha nettir. "Destek lideri" "takım" dan daha iyidir. Sahiplik kağıt üzerinde belirsizse, iş akışında da belirsiz kalır.

Süreci haritalarken insanları yavaşlatan noktalara yakın bakın: sonraki adımı engelleyen onaylar, eksik belgeler veya acil talepler gibi istisnalar, müşteri yanıtı gibi bekleme durumları ve artık değer katmayan yinelenen adımlar.

Küçük bir örnek yardımcı olur. Bir satın alma talebi SOP'sinde "yönetici talebi inceler" adımı, finans öncesi ve sonrası olmak üzere iki kez yer alıyor olabilir; oysa sadece bir onay kullanılıyorsa fazladan adım kaldırılmalıdır.

Eylemleri net durumlara dönüştürün

Yazılı prosedür genellikle ne yapılacağını söyler ama işin şu anda hangi aşamada olduğunu belirtmez. Bu yüzden takımlar takılır. Her öğeye insanların saniyede tarayabileceği küçük, net durumlar verin.

İyi durumlar tanıdık gelir. İnsanlar rehbere bakmadan ya da bir yöneticiye sormadan ne anlama geldiğini bilmelidir. Basit isimler genellikle en iyi çalışır: New, In review, Waiting for info, Approved, Done.

Sıralamayı kısa ve mantıklı tutun. Bir durumu yalnızca bir sonraki kişi için ne yapılması gerektiğini değiştirdiğinde ekleyin. Çok fazla adım yaratırsanız, insanlar panoyu işten zor olduğu için güvenmez olur.

Ayrıca durumların işi değil, işi tutan kişiyi tanımlamaması faydalıdır. "In review" "Waiting for manager"dan daha iyidir. Bir süpervizör yoksa başka biri devralsa bile iş akışı anlamlı kalır.

Aynı şekilde, bir öğeyi neyin ileri taşıdığını tanımlayın. Bir durum, bir olay gerçekleştiği için değişmelidir; birinin güncelleme yapma isteğine göre değil. Örneğin bir iade talebi için "New" form tamamlandığında "In review" olur. "In review" yönetici miktarı teyit ettiğinde "Approved" olur. "Waiting for info" eksik makbuz yüklendiğinde sona erer.

Durumlar basit ve gerçek olaylara bağlı olduğunda devirler hızlanır, hatalar azalır ve insanlar işin nerede olduğunu tahmin etmeyi bırakır.

Kararlar ve basit kurallar ekleyin

Pek çok SOP önemli seçimleri uzun cümlelerin içinde saklar. Bu seçimleri dışarı çekin ve net karar noktaları olarak yazın. Bir kişi durup "Bu eksikse ne olur?" veya "Bunu kim onaylıyor?" diye soruyorsa, kural hâlâ çok muğlak demektir.

Süreci oluşturan her evet veya hayır seçimiyle başlayın. Her birini spesifik tutun. "Müşteri gerekli belgeleri gönderdi mi?" iyi bir karardır. "Her şey yolunda mı?" ise değildir.

Her karar için her iki sonuçta da bariz bir sonraki adım olmalı. Yanıt evet ise ilerleyin. Yanıt hayır ise işin nereye gideceğini, kimin alacağını ve ne yapması gerektiğini açıkça gösterin. Bir karar sonrası kimse tahmin yapmamalıdır.

Basit bir test iyi çalışır: iki kişi kuralı okuyup aynı kararı vermeli. Kural gerçek bir veriye veya belgeye dayanmalı. Yeni bir ekip üyesi yardım almadan uygulayabilmeli. Ve sonraki adımı bir kısa cümleyle açıklayabilmelisiniz. Bunlardan herhangi biri başarısızsa, kuralı kısaltın.

İstisnalar da önemlidir. Birçok SOP onları notlarda, yan notlarda veya birinin hafızasında saklar. Bu durumları açığa çıkarın. Eksik evrak genellikle isteği engelliyor ama VIP hesaplar yönetici onayı ile ilerleyebiliyorsa, bu istisna kendi dalı olarak görünmelidir; paragrafta gömülü bir not olarak değil.

Yönetici incelemesini sadece gerçek risk, maliyet veya politika etkisi olan durumlar için kullanın. Her olağan dışı durum yöneticiye giderse iş akışı hızla yavaşlar. Daha dar kurallar daha iyi çalışır; örneğin belirli bir miktarın üzerindeki iadeler için onay veya hassas verilere erişim istekleri.

Sahipleri atayın ve devirleri görünür kılın

Bir görev "takıma" ait olduğunda iş akışı durur. Her durumun bir açık sahibi olmalı. Bu kişi işi ilerletmekten sorumludur; diğerleri görüntüleyebilir veya yardımcı olabilir ama sorumluluk nettir.

İsimler yerine rolleri düşünün. "İK müdürü inceler" "Sarah inceler"den daha iyidir çünkü insanlar iş değiştirir, izin alır ve birbirlerini kapsar. Bir görev açıldığında sahibi hemen belli olmalı.

Ayrıca kimlerin düzenleyebileceğini kimlerin onaylayabileceğini ayırmak iyi olur. Bunlar her zaman aynı kişi olmayabilir. Bir koordinatör eksik bilgileri doldurabilirken yönetici son onayı verir. Her iki eylem aynı grubun elindeyse insanlar birbirlerini beklemeye başlar veya yapılmaması gereken değişiklikler yapılır.

Basit bir kurulum şöyle görünebilir:

• Taslak: talep eden tarafından oluşturulur ve düzenlenir
• İnceleme: inceleyici tarafından ele alınır, bilgi eksikse geri gönderilir
• Onay: yönetici tarafından onaylanır veya reddedilir
• Tamamlandı: onaylanan işlem tamamlandıktan sonra kapatılır

Devir açık bir koşul yüzünden olmalıdır; birinin hatırlayıp mesaj atmasına bağlı olmamalıdır. Bir sonraki sahibi iş öğesini yalnızca doğru tetik gerçekleştiğinde almalıdır; örneğin form gönderildiğinde, bir onay kutusu işaretlendiğinde veya onay verildiğinde.

Örneğin bir satın alma talebi incelemedeyse, yönetici onayladıktan sonra ve tutar bütçe eşiğinin üzerindeyse Finans'a gitmelidir. Eşik altındaysa Finans'ı atlayıp doğrudan yerine getirmeye gidebilir.

Ayrıca yedek bir sahibi tanımlamak akıllıca olur. Ana sahip belirli bir süre için müsait değilse, öğe ikincil role veya ekip liderine geçmelidir. Bu küçük ayrıntı, birisi izinliyken işin ilerlemesini sağlar.

Gerçekten işe yarayan son tarihler ve bildirimler belirleyin

Son tarihler işi öne taşımalı, gürültü yaratmamalıdır. Onaylar, müşteri yanıtları, incelemeler veya ekipler arası devirler gibi sonucu gerçekten etkileyen adımlara son tarihler ekleyin.

İyi bir son tarih işin gerçek hızına uyar. Bir yönetici genellikle bir iş talebini bir iş günü içinde inceliyorsa, bunu hedef olarak belirleyin. Hukuki bir kontrol üç gün gerekiyorsa, süreci önemli hissettiği için o adımı acil ilan etmeyin.

Hatırlatmalar, bir görev geç kalmadan önce en iyi şekilde çalışır. Uzun işler için son tarihten 24 saat önce kısa bir hatırlatma genellikle yeterlidir. Daha kısa işler için, son tarihten bir veya iki saat önce hatırlatma insanların kovalanmadan harekete geçmesine yardımcı olabilir.

Bildirimleri dar tutun. Sıradaki kişi ne zaman sıra kendisine geliyorsa onu bilmelidir ve mevcut sahibi zaman daralırken haberdar edilmelidir. Çoğu zaman bütün takımın uyarılmasına gerek yoktur.

Güvenilir bir desen basittir: sahibi son tarihten önce hatırlat, durum "hazır" olduğunda sonraki kişiyi bilgilendir, sadece son tarih kaçırıldıktan sonra yükseltme yap, ve görev tamamlandığında hatırlatmaları durdur.

Yükseltme nadir ve açık olmalıdır. Küçük gecikmelerin hepsi yöneticinin önüne gelirse insanlar dikkat etmemeye başlar. Süreci engelleyen veya müşteriyi etkileyen kaçırılmış son tarihler için yükseltme saklayın.

Mesaj kısa ve belirgin olmalı: "Tedarikçi talebini bugün 15:00'e kadar onaylayın" "Bekleyen iş öğeniz var"dan çok daha etkilidir.

Basit bir örnek: yeni çalışan işe alımı

İyi bir işe alım akışı tek bir net tetikleyiciyle başlar: işe alan yönetici, yeni çalışan teklifi imzaladığında talebi gönderir. Bu talep sadece temel bilgileri almalıdır: başlangıç tarihi, rol, bölüm, yönetici, çalışma yeri ve ihtiyaç duyulan araçlar veya erişimler.

Bundan sonra işler birkaç net onayın üzerinden geçer. İK çalışan bilgilerini kontrol eder ve başlangıç tarihini onaylar. Takım lideri yazılım erişimi, ekipman ve eğitim gibi role özel ihtiyaçları onaylar. Dağınık mesajlar yerine iş akışı her adımı doğru kişiye sırayla gönderir.

Durumlar gerçek ilerlemeyi yansıtmalıdır, belirsiz güncellemeleri değil. "Ekipman hazır" ifadesi, dizüstü bilgisayarın atanıp hazırlandığı anlamına gelmelidir, sadece sipariş edildiği değil. "Erişim verildi" hesapların aktif ve test edildiği anlamına gelmelidir.

Karar kuralları basit kalmalıdır. Çalışan uzaktaysa iş akışı ekipman için gönderim görevini eklemelidir. Rol özel araçlar gerektiriyorsa ekstra erişim istekleri oluşturulmalıdır. Eğitim zorunluysa süreç oturum planlanana veya tamamlanana kadar açık kalır.

Son tarihler insanların zamanında harekete geçmesine yardımcı olur. İK onayı bir iş günü içinde olmalı, ekipman kurulumu başlangıç tarihinden üç gün önce tamamlanmalı, eğitim ilk haftanın sonunda planlanabilir. Bir son tarih yaklaşıyorsa sahibi bir hatırlatma alır, yöneticinin güncelleme kovalamamasını beklemez.

Süreç ancak tüm gereken işler tamamlandığında kapanmalıdır: onaylar tamam, ekipman hazır, erişim çalışıyor ve eğitim yapıldı.

Süreci yavaşlatan yaygın hatalar

İş akışı işi takip etmeyi kolaylaştırmalı, ama birkaç yaygın hata basit bir SOP'yi insanların kaçınacağı, göz ardı edeceği veya etrafından dolanacağı bir şeye çevirebilir.

En büyük problemlerden biri çok fazla durum yaratmaktır. Bir görev, sonraki adımı gerçekten değiştirmeyen küçük etiketlerden geçiyorsa insanlar pano umursamaz hale gelir. Yararlı bir durum gerçek bir soruyu yanıtlamalı: bekliyor mu, ilerlemede mi, engellendi mi, onaylandı mı veya tamamlandı mı?

Diğer bir problem hafızaya dayalı kurallar oluşturmaktır. SOP "gerekli olduğunda gönder" veya "durum alışılmadık görünüyorsa finansla sor" diyorsa süreç hala birinin kafasında yaşıyordur. Farklı insanlar farklı seçimler yapacaktır.

Diğer sürtüşme noktaları çabuk ortaya çıkar: sahibinin belli olmadığı görevlere takılı son tarihler, büyük gruplara gönderilen bildirimler herkesin başkasının yapacağını varsaymasına yol açar ve sıradışı istekler veya eksik bilgiler için tanımlı bir yol yoksa insanlar kendi çözümlerini icat eder.

Son tarihlerin kağıt üzerinde iyi görünüp gerçek işte başarısız olmasının bir nedeni vardır: kimse onlara sahip değildir. Bir inceleme iki gün içinde teslim edilecekse, bir kişinin o incelemenin sahibi olması gerekir. Aksi takdirde son tarih öneriye dönüşür.

Bildirimler de eylem yaratmak yerine gürültü üretebilir. Her güncellemeyi tüm takım gelen kutusuna göndermek güvenli hissettirebilir ama genellikle yanıt süresini yavaşlatır. Önce sadece işlem yapması gereken kişiyi bilgilendirmek ve sonra son tarih kaçırıldıysa yedek eklemek daha iyidir.

Uç durumlar özel dikkat ister. Her süreçte olur: eksik belgeler, yinelenen talepler, çatışan onaylar veya normal yola uymayan talepler. Tanımlı bir istisna yolu yoksa insanlar kendi yöntemlerini uydurur ve o zaman izleme bozulur.

Basit bir test yardımcı olur: iş akışını tasarlamayan birine verin. Eğer onlar bir sonraki adımın ne olduğunu, kimin sahip olduğunu ve bir sorun çıktığında ne yapacaklarını söyleyemiyorsa, süreç hâlâ çok kırılgandır.

Yayına almadan önce hızlı kontroller

İş akışını günlük kullanıma sokmadan önce son bir gerçeklik kontrolü yapın. Bir iş akışı ekranda düzenli görünebilir ama gerçek bir kişi zaman baskısı altında denediğinde başarısız olabilir.

En hızlı test basittir: yeni birine verin. Eğer kişi bir durumu, kimin sırada olduğunu veya bir karardan sonra ne olacağını sormadan bir görevi baştan sona taşıyabiliyorsa epey yakınsınız demektir.

Her adımın bir sahibi olduğundan emin olun. Her karar noktasını gözden geçirip her cevabın açık bir sonraki eyleme yol açtığını doğrulayın, ölümcül bir çıkmaz olmasın. Hatırlatmaların ve son tarihlerinin gecikmeyi önleyecek kadar erken geldiğini kontrol edin. Sonra iş akışı görünümünü açın ve engellenmiş işlerin hemen fark edilebildiğinden emin olun. Ne beklediğini, kimin beklediğini ve ne kadar süredir beklediğini görmelisiniz.

Küçük bir örnek bunu netleştirir. Yeni çalışan işe alım akışında "İlerliyor" çok muğlak olabilir. İK belgeleri topluyor mu, BT erişim kuruyor mu yoksa yönetici ekipman onaylıyor mu? Net isimler gecikmeleri daha kolay tespit etmeyi sağlar.

Kararlar için de aynı şey geçerlidir. "Onaylandı" sadece orada durmamalı. Görevi otomatik olarak ilerletmeli veya bir sonraki kişiyi atamalı. "Daha fazla bilgi gerekli" bir seçenekse, aynı zamanda doğru kişiye bir mesaj ve son tarih tetiklemelidir.

Sonraki adım

Küçük başlayın. İş akışını bir kağıt testiyle değil gerçek bir vaka ile çalıştırın. Gerçek bir vaka insanların nerede tereddüt ettiğini, hangi alanın belirsiz olduğunu ve hangi devirin beklenenden uzun sürdüğünü gösterir.

İlk çalıştırmayı yakından izleyin. Sadece adımların çalışıp çalışmadığını kontrol etmiyorsunuz. İnsanların bunları yardım almadan takip edip edemediğini kontrol ediyorsunuz.

Birkaç soru genellikle zayıf noktaları ortaya çıkarır: Nerede durup düşünmek zorunda kaldınız? Nerede başkasını beklediniz? Hangi durum belirsiz veya çok geniş hissettirdi? Hangi bildirim yardımcı oldu, hangisi sadece gürültüydü?

Geri bildirimi pratik tutun. Kullanıcılar "Onaydan sonra ne yapacağımı bilmiyordum" derse, durum ismi netleşmeli veya sonraki eylem otomatik görünmelidir. "Son tarihi kaçırdım" derlerse hatırlatma çok geç olabilir veya sahip yanlış atanmıştır.

Değişiklikleri tüm takıma yaymadan önce yapın. Durum isimlerini sıkılaştırın, karar kurallarını basitleştirin ve insanlar tarafından görmezden gelinecek bildirimleri kaldırın. Bir kural uzun bir açıklama gerektiriyorsa muhtemelen çok karmaşıktır.

Yararlı bir sonraki adım, herkesle birlikte tamamlanmış bir vakayı 10 dakika gözden geçirmektir. Nerede yavaşladığını ve neyin sorunsuz işlediğini bakın. Bu kısa gözden geçirme genellikle bir sonraki çalıştırmayı iyileştirmek için yeterlidir.

Kodu olmadan süreci oluşturmak isterseniz, AppMaster bir seçenek olabilir: bir SOP'yi formlar, iş mantığı, durumlar ve bildirimlerle tek bir dahili uygulamaya çevirmenize yardımcı olur. Bir iş akışı iyi çalıştıktan sonra aynı yaklaşımı bir sonraki SOP için tekrarlayın. Bir düzgün süreç on yarım bırakılmış olandan daha değerlidir.