Süreç dokümantasyonu (SOP): devredilebilir bir iş nasıl yazılır?
Standart işletim prosedürü yazmanın yapısı, kimin yazması gerektiği, güncel tutma disiplini ve dokümanın gerçekten kullanıldığını anlamanın yolları.
Her şirkette bir "o bilir" kişisi vardır. Bir süreci yalnızca o yürütür, adımlarını yalnızca o hatırlar ve izne çıktığında iş durur.
Süreç dokümantasyonu, bu bağımlılığı çözmenin yolu. Ama çoğu şirkette yazılan prosedürler kimsenin okumadığı belgeler olarak kalıyor — çünkü yanlış kişi, yanlış biçimde yazıyor.
Kim yazmalı?
Yaygın yanlış: prosedürü yöneticinin ya da bir kalite uzmanının yazması. Sonuç, işin gerçekte nasıl yapıldığını değil, nasıl yapılması gerektiği varsayılan hâlini anlatan bir metin oluyor.
Doğrusu: işi yapan kişi yazar, bir başkası okuyup uygular. İkinci adım kritik — dokümanı hiç okumamış biri adımları takip edip işi tamamlayabiliyorsa doküman iyidir, tamamlayamıyorsa eksiktir. Bu test, yazımdan daha değerli.
Neyi dokümante etmeli?
Her şeyi değil. Öncelik sırası:
Yüksek risk, düşük sıklık. Yılda iki kez yapılan ama yanlış yapıldığında pahalıya mal olan işler — yıl sonu kapanışı, denetim hazırlığı, sistem yedekten dönüş. Kimse hatırlamıyor çünkü nadir, ve tam da bu yüzden yazılı olmalı.
Tek kişiye bağlı işler. Yedeği olmayan her süreç. Riski yetenek yönetimi ve yedekleme planı yazısında ele aldık.
Yeni başlayanın öğrenmesi gereken işler. Oryantasyonun bir parçası; işe alıştırma süreci yazısına bakın.
Uyum gerektiren işler. Denetime tabi süreçler; kayıt tutma yükümlülüğü zaten var.
Günlük, herkesin bildiği rutin işleri yazmak zaman kaybı — ve doküman kalabalığı, gerçekten önemli olanı görünmez kılıyor.
İyi bir SOP'un yapısı
Altı bölüm yeterli:
- Amaç ve kapsam — bu süreç ne zaman uygulanır, ne zaman uygulanmaz?
- Sorumlu roller — kim yapar, kim onaylar, kim bilgilendirilir?
- Ön koşullar — hangi erişim, hangi belge, hangi sistem gerekli?
- Adımlar — numaralı, tek eylem içeren cümleler. Ekran görüntüsü varsa çok daha iyi.
- Sık karşılaşılan sorunlar — "şu hata çıkarsa şunu yap". Deneyimin en değerli kısmı burada.
- Sahip ve gözden geçirme tarihi.
Beşinci madde, dokümanı "prosedür" olmaktan çıkarıp gerçekten faydalı kılan şey. Adımları herkes yazabiliyor; hangi noktada ne ters gittiğini yalnızca işi yapan biliyor.
Örnek: bir devir teslimin sınanması
Bir finans ekibinde aylık raporlama sürecini tek kişi yürütüyor. Ayrılma kararı verince iki haftalık devir teslim planlanıyor ve bir doküman yazılıyor.
Doküman "yazıldı" sayılmıyor; yeni kişi, ayrılan kişi hâlâ oradayken ilk ayı tek başına dokümanla yürütüyor. Takıldığı her noktada soru soruyor ve cevap doğrudan dokümana ekleniyor.
Ay sonunda doküman ilk hâlinden iki kat uzun. Eklenenlerin çoğu adım değil, istisna: "şu tarih hafta sonuna denk gelirse", "şu sistemde kur farkı çıkarsa", "onay gelmezse kime yazılır".
Bu ikinci yarı, ilk yazımda hiç akla gelmeyen ama işin gerçek zorluğunu oluşturan kısım. Devir teslimi "doküman teslim edildi" ile bitiren şirketler, tam da bu kısmı kaybediyor. Vardiya ve ekip arası devir disiplinini vardiya yönetimi ve devir teslim yazısında ele aldık.
Nerede yaşamalı?
SOP'lar aranabilir, sürümlü ve erişim kontrollü bir yerde durmalı — wiki ya da doküman merkezi.
Kişisel bilgisayarlarda ve e-posta eklerinde duran prosedürler, olmayan prosedürlerle aynı değere sahip. Sürüm takibinin neden kritik olduğunu doküman yönetimi ve sürüm takibi yazısında ele aldık.
Güncel tutmak
Eskimiş bir prosedür, hiç olmamasından daha tehlikeli: insanlar ona güvenip yanlış adımı atıyor. Üç mekanizma:
- Gözden geçirme tarihi: her dokümana bir tazelik tarihi, geçtiğinde sahibine otomatik hatırlatma. Mekanizmayı planlı yayın ve tazelik denetimi yazısında anlattık.
- Değişiklik tetikleyicisi: sistem ya da mevzuat değiştiğinde ilgili SOP'ların güncellenmesi, değişiklik kontrol listesinin maddesi olsun.
- Kullanım anında düzeltme: dokümanı kullanan kişi eksik gördüğünde doğrudan düzeltebilmeli ya da not bırakabilmeli.
Dokümantasyonu bir projeye dönüştürmemek
Süreç yazımı, "bu yıl tüm prosedürlerimizi dokümante edeceğiz" diye başlatılan projelerde çoğunlukla yarıda kalıyor. Sebep, işin büyüklüğü: yüzlerce süreç, hepsi aynı anda, kimsenin asıl işinin üstüne.
Daha sürdürülebilir yaklaşım, dokümantasyonu bir proje değil bir alışkanlık hâline getirmek:
- Tetikleyiciye bağlayın. Yeni biri işe başladığında, bir süreç değiştiğinde ya da biri izne çıkacağında o sürecin dokümanı yazılır veya güncellenir.
- Soru geldiğinde yazın. Birine bir süreci ikinci kez anlatıyorsanız, anlatırken yazın. Üçüncü kez soran kişiye bağlantıyı gönderin.
- Küçük tutun. Bir sayfalık on doküman, otuz sayfalık bir el kitabından çok daha fazla kullanılıyor.
Bu yaklaşımda ilk yıl sonunda elinizde eksiksiz bir kütüphane olmuyor — ama gerçekten kullanılan, güncel ve en kritik süreçleri kapsayan bir set oluyor. Tam kapsam hedefiyle başlayan projelerin çoğunda ise ikinci yıl hiçbir şey kalmıyor.
Sık sorulan sorular
Video mu metin mi? Metin aranabilir, güncellenebilir ve hızlı taranabilir; video ise arayüz gösteriminde üstün. İkisi birlikte iyi çalışıyor: metin ana kaynak, video destekleyici. Videonun ne zaman değdiğini iç iletişimde video kullanımı yazısında tartıştık.
Ne kadar ayrıntı? Dokümanı hiç bilmeyen birinin uygulayabileceği kadar. Bu eşik, yazarın tahmininden her zaman daha ayrıntılı çıkıyor.
Kim onaylamalı? Sürecin sahibi ve etkilenen birim. Uyum gerektiren süreçlerde ayrıca ilgili uzman. Onay zincirini talep formu şablonları ve onay zinciri mantığıyla kurabilirsiniz.
Yapay zekâ asistanı SOP'ları okuyabilir mi? Evet ve bu, dokümantasyonun getirisini artırıyor: iyi yazılmış prosedürler, doğal dille sorulan sorulara cevap üretebilen bir kaynağa dönüşüyor. Mimariyi intranette yapay zekâ asistanı yazısında ele aldık.