Standart operasyon prosedürü örnekleri: 3 uygulamalı SOP
Adımları, kullanılan sistemleri ve istisnalarıyla üç standart operasyon prosedürü (SOP) örneğini inceleyin. Bir SOP’nin neleri içermesi ve nasıl güncel tutulması gerektiğini öğrenin.
Standart operasyon prosedürü örneği, yalnızca başlıkları değil, uygulamadaki adımları, kullanılan sistemleri ve istisnaları da göstermelidir. Aşağıda, adım adım açıklanan üç örneği; güncel tutabileceğiniz bir prosedürün temel bölümlerini, prosedürü işin yapıldığı yerde nasıl belgeleyeceğinizi ve hâlâ uygulamayı yansıtıp yansıtmadığını nasıl kontrol edeceğinizi bulabilirsiniz.
Standart operasyon prosedürü nedir?
SOP, tekrarlanan bir işin nasıl yapıldığını açıklar: işi kimin, hangi sırayla ve hangi sistemde yapacağını, olağan yol izlenemediğinde ne yapılacağını belirtir. Ekibin işin yürütülmesi ve yeni çalışanların eğitimi için ortak bir kaynağa başvurmasını sağlar. Ancak SOP’nin niteliği, yapılan işle en son ne zaman karşılaştırıldığına bağlıdır.
SOP; politika, iş talimatı veya süreç haritasından nasıl ayrılır?
Bu belgelerin her biri farklı bir amaca hizmet eder:
- Politika kuruluşunuzun aldığı kararları belirtir. Örneğin: “10.000 üzerindeki tüm faturalar için iki kişinin onayı gerekir.”
- İş talimatı, kullanılacak ekranı, alanı veya düğmeyi açıklayarak belirli bir adımın nasıl yapılacağını gösterir. SOP sırada ne olduğunu, iş talimatı ise o adımın nasıl yapılacağını anlatır.
- Süreç haritası, işin roller ve sistemler arasında nasıl ilerlediğini gösterir. SOP ise tek bir işi daha ayrıntılı açıklar. Süreç haritalama rehberimize göz atın.
SOP’yi, karar vermesi veya bir istisnayı ele alması gereken durumlar dâhil, işi yapan kişinin ihtiyaçlarına göre yazın.
Üç standart operasyon prosedürü örneği
Her örnekte rolü, sistemi, beklenen çıktıyı ve istisna yolunu içeren bir adım tablosu bulunur. Bu ayrıntılar, prosedürü izlemeyi ve sistemlerinizde kayıtlı işlerle karşılaştırmayı kolaylaştırır.
Örnek 1: Paylaşımlı hizmetlerde fatura istisnalarının ele alınması
Bu prosedür, fatura üç yönlü eşleştirmeden geçemediğinde başlar. İstisna sütunu, bir adım planlandığı gibi ilerlemediğinde ne yapılacağını açıklar.
| Adım | Kim | Sistem | Çıktı | Sorun çıkarsa |
|---|---|---|---|---|
| 1 | Borçlar muhasebesi görevlisi | ERP | Neden koduyla birlikte istisna kaydı oluşturulur | Neden kodu yoksa incelemeye başlamadan önce borçlar muhasebesi ekip liderine yönlendirin |
| 2 | Borçlar muhasebesi görevlisi | ERP, tedarikçi portalı | Fiyat, miktar veya teslimat farkı belirlenir | Fiyat %2 tolerans aralığındaysa faturayı kaydedin ve varyansı günlüğe ekleyin |
| 3 | Satın almacı | ERP | Malların sipariş edildiği şekilde teslim alındığı doğrulanır | Satın almacı 2 gün boyunca ulaşılmazsa kategori yöneticisine iletin |
| 4 | Borçlar muhasebesi görevlisi | ERP | Alacak dekontu talep edilir veya fatura ödeme için onaylanır | Tedarikçi alacak dekontuna itiraz ederse uyuşmazlık prosedürüne geçin, kaydı açık bırakmayın |
| 5 | Borçlar muhasebesi ekip lideri | ERP | Neden kaydedilerek kayıt kapatılır | Aynı neden kodu art arda üç ay görünürse süreç değişikliği talebi oluşturun |
Son satır, ekibin tekrarlanan bir sorunu incelemeye almasını sağlar. Her istisnanın aynı şekilde çözüleceğini varsaymaz.
Örnek 2: Malların teslim alınması ve yerleştirilmesi
| Adım | Kim | Sistem | Çıktı | Sorun çıkarsa |
|---|---|---|---|---|
| 1 | Mal kabul görevlisi | WMS | Teslimat ASN ile karşılaştırılarak kontrol edilir | ASN yoksa manuel teslim alma kaydı oluşturun ve tedarikçiyi işaretleyin |
| 2 | Mal kabul görevlisi | WMS | Miktar ve hasar kaydedilir | Hasar varsa fotoğrafını çekin, paleti karantinaya alın ve satın alma ekibine bildirin |
| 3 | Kalite denetçisi | QMS | Parti için serbest bırakma kararı verilir | Parti beklemedeyse malları karantinada tutun, yerleştirmeye başlamayın |
| 4 | Depo görevlisi | WMS | Mallar önerilen konuma yerleştirilir | Konum kapalıysa taşma alanındaki gözü kullanın ve bunu kaydedin |
| 5 | Depo görevlisi | WMS | Stok, sipariş toplama için kullanılabilir duruma gelir | Teslim alma kaydı son işlem saatinden sonra girildiyse açık siparişlerin yeniden planlanması gerekip gerekmediğini kontrol edin |
Örnek 3: BT hizmet masasında olayları önceliklendirme
| Adım | Kim | Sistem | Çıktı | Sorun çıkarsa |
|---|---|---|---|---|
| 1 | Hizmet masası temsilcisi | ITSM | Hizmet, etki ve aciliyet bilgileriyle olay kaydedilir | Kullanıcıya ulaşılamıyorsa kaynağı belirterek kullanıcı adına kayıt oluşturun |
| 2 | Hizmet masası temsilcisi | ITSM, CMDB | Etki ve aciliyet matrisine göre öncelik belirlenir | Çözüm ekibi önceliğe itiraz ederse hizmet sorumlusuna iletin, konuyu sessizce yeniden müzakere etmeyin |
| 3 | Çözüm ekibi | ITSM | SLA süresi içinde teşhis ve çözüm girişimi yapılır | Çözüm için değişiklik gerekiyorsa değişiklik kaydına bağlantı verin ve olayı açık tutun |
| 4 | Hizmet masası temsilcisi | ITSM | Kullanıcı onayı alınır ve kayıt kapatılır | Kullanıcı 3 gün içinde onay vermezse nedeni kaydederek kapatın |
SOP’de neler bulunmalı?
Bir sonraki standart operasyon prosedürünüzü hazırlarken bu yapıyı başlangıç noktası olarak kullanın:
- Amaç ve kapsam: Prosedürün neleri kapsadığını, neleri kapsamadığını belirtin. Net sınırlar, her SOP’nin tek bir işe odaklanmasına yardımcı olur.
- Tetikleyici: Okuyucunun prosedürün ne zaman uygulanacağını anlayabilmesi için prosedürü başlatan olayı belirtin.
- Roller: Sorumlulukları kişilere göre değil, rollere göre belirtin. Kişiler değişir, roller daha kalıcıdır.
- Numaralı adımlar ve sistemler: Her adımı, kimin gerçekleştirdiğini ve hangi sistemi kullandığını açıklayın.
- İstisna yolu: Olağan yol izlenemediğinde ne yapılacağını açıklayın. Yalnızca ideal durumu değil, sık karşılaşılan sapmaları da ekleyin.
- Kontroller ve kanıtlar: Nelerin, nereye kaydedileceğini ve ne kadar süre saklanacağını belirtin.
- Sorumlu ve değişiklik geçmişi: Sorumlu kişiyi belirtin; her değişikliğin tarihini ve niteliğini kaydedin.
- Gözden geçirme tetikleyicisi: Sistem, mevzuat veya ekip değişikliği ya da ölçülen performansta kayma gibi hangi durumların gözden geçirmeyi başlatacağını belirtin.
Değişiklik geçmişi, nelerin ne zaman değiştiğini gösterir. Gözden geçirme tetikleyicisi ise prosedür güncelliğini yitirmeden önce yeniden incelemeniz için bir neden sunar.
Bir SOP’nin kullanıma hazır olup olmadığını nasıl kontrol edebilirsiniz?
Prosedürü yayımlamadan veya güncellemeden önce şu soruları sorun:
- Kapsam, SOP’nin neleri kapsamadığını belirtiyor mu?
- Tetikleyici, başlangıç bölümünde açıkça belirtilmiş mi?
- Her adımda bir rol, bir sistem ve beklenen bir çıktı belirtiliyor mu?
- Bir uygulamada gerçekleştirilen adımlar, okuyucunun göreceği ekranı gösteriyor mu?
- Prosedür, olağan yol izlenemediğinde ne yapılacağını açıklıyor mu?
- Adı belirtilmiş bir sorumlu ve değişiklik geçmişi var mı?
- Belirli bir olay gözden geçirmeyi başlatıyor mu?
- Prosedürü olay verileriyle karşılaştırabilir misiniz ve farklılıkları süreç sorumlusuyla birlikte kontrol ettiniz mi?
Son soruya yanıt veremiyorsanız önce işin hangi sistemlerde kaydedildiğini belirleyin. Böylece prosedürün uygulamada yapılan işi hâlâ yansıtıp yansıtmadığını kontrol edebilirsiniz. SOP süreci de yalnızca belge dosyalamaktan çıkar, düzenli bir gözden geçirme döngüsüne dönüşür.
SOP’ler nasıl yönetilir?
SOP’yi oluşturmak işin kolay kısmıdır. Asıl zorluk SOP programını yönetmektir: prosedürün nerede tutulacağı, hangi sürümün güncel olduğu ve kimin gözden geçireceği. Özel standart operasyon prosedürü yönetim yazılımı kullansanız da belgeleri bir klasörde tutsanız da her ekibin ayrı bir kopyası zamanla güncelliğini yitirir. ProcessMind, prosedürü açıkladığı süreçle birlikte tutar; böylece yönetişim bilgileri metinle birlikte kalır:
- Prosedürü açıkladığı etkinliğe ekleyin. Her sürecin, ortam düzeyinde bir kez yapılandırılan dokümantasyon ağacı vardır. Böylece her prosedür aynı açıklama, kapsam, roller, hedefler ve yönetişim başlıklarıyla başlar. Kuruluşunuzun ihtiyaç duyduğu özel bölümleri ekleyin. İş talimatını da birinin bulması gereken ayrı bir klasörde değil, ait olduğu adımın yanında tutun.
- Süreçle birlikte gözden geçirin. Süreç taslak, inceleniyor, onaylandı, yayımlandı, emekli ve arşivlendi aşamalarından geçer. İnceleme bekleyenler, İncelemeniz gerekiyor filtresinde işlerini bulur. Onayla aynı adımda yayımlanmış bir sürüm oluşturulabilir. Böylece bir belge bir yerde onaylanıp başka bir yerde değiştirilmez.
- İşin yapıldığı yerde yorum yapın. Bir adıma Yorum ekle seçeneğiyle yorum eklediğinizde o etkinlik için bir görüşme başlar. Böylece alan, kontrol veya istisnayla ilgili sorular gelen kutusunda kaybolmak yerine talimatın yanında kalır.
- Sürümleri saklayın. Sürüm geçmişi nelerin, ne zaman ve kim tarafından değiştirildiğini kaydeder. Yayımlama ise okuyucuların hangi sürümü göreceğini belirler.
- Rolleri modelden alın. Belgedeki RACI matrisi, modeldeki etkinliklere atanmış rollerle doldurulur. Böylece metindeki sorumluluklar diyagramdaki sorumluluklarla örtüşür.
- Ekran adımlarını, işin ekranda yapıldığı yerde kaydedin. ProcessMind içinden ekran görüntüsü veya ekran kaydı alın, önemli kontrolleri gösterecek şekilde kırpın, kişisel bilgileri kaydedilen görüntüde kalıcı olarak kapatın ve Markdown biçiminde talimat ekleyin. Düzenleyici, hassas olabilecek alanları sizin için algılayabilir. Kutular düzenlenebilir durumda kalır; kaydetmeden önce düzeltme yapabilirsiniz. Görüntü, etkinliğe eklenen bir artefakt olarak saklanır.
- Dosyaya ihtiyaç duyan okuyucular için dışa aktarın. Gözden geçirme döngüleri ve kalite yönetim sistemi için Word, sürüm denetimi için Markdown, dağıtım ve arşivleme için PDF veya baskı kullanın. Dışa aktarma ayarları, çıktıda henüz belgelenmemiş model öğelerinin, süreç grafiklerinin ve etkinlik başına RACI matrisinin yer alıp almayacağını belirler. Belgelenmemiş öğeleri listelemek, prosedürdeki boşlukları görmenin genellikle en hızlı yoludur.
Belge işin bir yarısıdır. Diğer yarısı da kontrol sürecidir ve aynı yerde yürütülmelidir: belgelenen adımları sistemlerinizde kaydedilen etkinlikle karşılaştırın, ardından eğitimin, belgenin veya sürecin değişmesi gerekip gerekmediğine karar verin. Onaylanan değişiklik, kendi sürüm durumuyla dokümantasyona eklenir.
İki sınırı açıkça belirtmekte fayda var. ProcessMind kayıtları düzenler ve inceleme için kanıt sunar; uyumluluğu belgelendirmez, kalite yönetim sisteminizin gerektirdiği onayın veya hukuk ekibinizin yönettiği politika kitaplığının yerini almaz. Bu iş akışının dışında çalışan ekran kaydı araçları, örneğin Scribe, birinin görevi nasıl tamamladığını aynı şekilde kaydedebilir. Tek bir ekibin yönettiği birkaç prosedür için wiki de yeterli olabilir. Ancak ne wiki ne de ayrı bir belge deposu, prosedürün hâlâ yapılan işle örtüşüp örtüşmediğini gösterir.
Yazılı prosedürler neden işleyişten uzaklaşır?
Prosedürler zamanla işleyişten uzaklaşır; çünkü dokümantasyon hazırlandıktan sonra işler değişir. Bu, mutlaka yazım hatası olduğu anlamına gelmez. Sürecin geliştiğini gösterir.
Prosedür hafızaya dayanır. Bir çalıştay, insanların süreci nasıl anladığını ortaya koyar. Ancak bu, sürecin nasıl yürütüldüğünden çok nasıl tasarlandığını yansıtabilir. İşin büyük bölümünü oluşturabilmelerine rağmen istisnalar kolayca gözden kaçar.
Ekipler geçici çözümler geliştirir. Bir çalışan sık karşılaşılan bir durum için daha hızlı bir yol bulup bunu iş arkadaşlarıyla paylaşabilir. SOP’yi güncellemek, bu geçici çözümü kullanmaktan daha çok çaba gerektiriyorsa doküman güncelliğini yitirebilir.
Sistemler değişir. Bir alanın adı değişir, bir kontrol otomatikleşir ya da onay eşiği farklılaşır. Prosedür hâlâ önceki düzeni anlatıyor olabilir.
Değişikliği fark etmek zordur. Yazılı bir doküman, işleyişin ne zaman farklılaşmaya başladığını göstermez. Süreçten kanıtınız yoksa ne olduğunu anlamak için çalışanlardan yaşananları yeniden anlatmalarını isteyebilirsiniz.
Prosedürün güncel kalmasını sağlayan nedir
Bir klasörde duran doküman bu soruyu tek başına yanıtlayamaz. Prosedürü canlı tutmak yanıtlayabilir: Prosedür sürece ve anlattığı etkinliğe bağlı kalır. Böylece bir adımdaki değişiklikle dokümantasyondaki değişiklik, modelde adı geçen roller tarafından birlikte gözden geçirilir. Yayımlanan sürüm, ekibinizin Process Portal’da başvurduğu tek doğru bilgi kaynağıdır. Dışa aktarılan her dosya da birinin yerel olarak düzenlediği kopyadan değil, bu kayıttan oluşturulur.
İki unsur, prosedürün işleyişle uyumlu kalmasına yardımcı olur. Uyumluluk kontrolü, dokümante edilen süreçle sistemlerinizin kaydettiği etkinlikler arasındaki farkı ölçer. Böylece süreçteki sapmaları tahmin etmek yerine inceleyebilirsiniz. Süreç yönetişimi bu yanıtın sorumluluğunun kimde olduğunu netleştirir. Yönetişim ve yayımlama ise inceleme ve sürüm bilgilerinin tutulduğu yerdir.
Yazılı prosedür, işleyiş değiştikten sonra güncelliğini yitirir; o noktada da kimse değişimin ne zaman başladığını söyleyemez. Prosedürü, anlattığı etkinliğin yanına, sürecin üzerine yerleştirmek, bu değişikliği erkenden fark etmenin bildiğim tek yolu. Belgeyi ve kanıtları birlikte inceleyin; yoksa biri her zaman güncelliğini yitirir.
Olay verilerinden SOP nasıl hazırlanır?
Olay verileri, ERP, ITSM veya WMS gibi işleyişi zaten kaydeden sistemlerde insanların hangi adımları izlediğini gösterir. Bir prosedür taslağı hazırlarken ve gözden geçirirken bu verileri süreç bilgisiyle birlikte kullanın. Process Mining kullanım alanlarından biri de budur:
-
Event Logu yükleyin
Süreci kaydeden sistemlerde vaka kimliğini, etkinliği ve zaman damgasını belirleyin. Karşılaştırmayı tutarlı kılmak için tek bir vaka tanımı ve tek bir zaman aralığı kullanın. -
Dokümante edilen süreçle eşleştirin
Kaydedilen adımları SOP’deki adımların yanına koyun. Dokümante edilen bazı adımlar her vakada görülür, bazıları nadiren görülür, bazılarıysa hiç görülmez. Her biri soru sormaya değer. -
Farklılıkları analiz edin
Her yolun ne sıklıkta izlendiğini, işin nerede beklediğini ve hangi adımların tekrarlandığını ölçün. Verilerdeki farklılıklar, işleyişin yanlış olduğunun kanıtı değil, araştırma nedenidir. -
Önemli farklılıkları SOP’ye ekleyin
Yukarıdaki üç örnekte olduğu gibi, tekrarlanan durumları rolü, sistemi ve beklenen çıktıyı belirten istisna satırlarına dönüştürün. Verilerin gösteremediği noktaları doğrulamak için işi yapanlara danışın.
Prosedürü kontrol etmek için süreç verilerinden yararlanabilirsiniz; ancak bu veriler her kararın nedenini açıklamaz ve sürecin nasıl olması gerektiğini belirlemez. Bulguları işi yapan ve sahiplenen kişilerle doğrulayın. Bu sırada bir sorumlu ve gözden geçirme tetikleyicisi belirleyin: Sahibi olmayan bir prosedür zamanla güncelliğini yitirir.
Where to Go From Here
You have a procedure and a way to check it. Compare the documented steps with the activity your systems already record, and use the differences to decide what to review with your process team.
