SOP Nedir? Standard Operating Procedure Nasıl Yazılır?

Bir işi şirkette yalnızca bir kişi doğru yapabiliyorsa ortada süreçten çok kişiye bağımlılık vardır.

O kişi izin aldığında, ekip değiştirdiğinde veya şirketten ayrıldığında operasyonun kalitesi düşüyorsa sorun çalışanların geri kalanının yetersizliği olmayabilir.

Süreç yeterince tanımlanmamış olabilir.

Standard Operating Procedure, kısaca SOP, tekrar eden bir operasyonun nasıl yürütüleceğini tanımlayan kontrollü çalışma prosedürüdür.

Ancak SOP’u yalnız:

Bir işi nasıl yapacağımızı anlatan adım adım doküman.

şeklinde tanımlamak eksiktir.

Daha kullanışlı tanım şudur:

SOP; tekrar eden bir operasyonun hangi koşullarda, kim tarafından, hangi yöntemle, hangi karar kuralları, kontrol noktaları, kabul kriterleri ve kayıt gereksinimleri altında gerçekleştirileceğini tanımlayan operasyonel sistemdir.

EPA, SOP’ları rutin veya tekrar eden işleri belgeleyen ve süreçlerin teknik ve kalite gereksinimlerine tutarlı biçimde uygulanmasını destekleyen yazılı prosedürler olarak ele alır.

ISO’nun süreç yaklaşımı ise daha geniş resmi gösterir: organizasyonlar girdileri belirli çıktılara dönüştüren süreçler üzerinden çalışır ve bu süreçlerin ihtiyaç duyulan ölçüde tanımlanması, kontrol edilmesi ve dokümante edilmesi gerekir.

Bu nedenle SOP’un asıl ürünü Word, Notion veya PDF dosyası değildir.

SOP’un ürünü öngörülebilir bir süreçtir.

SOP hangi problemi çözer?

SOP’un merkezindeki problem process variation, yani süreç varyasyonudur.

Üç SEO uzmanından yeni bir müşterinin teknik SEO auditini yapmalarını istediğimizi düşünelim.

Birinci uzman:

Crawl
↓
Search Console
↓
Sitemap
↓
Canonical
↓
Internal Linking

sırasıyla ilerliyor.

İkinci uzman doğrudan Search Console’a giriyor.

Üçüncü uzman sitemap ile crawl verisini hiç karşılaştırmıyor.

Üçü de sonuçta:

Technical SEO audit yaptım.

diyor.

Fakat aynı isim altında üç farklı süreç çalışıyor.

Bu fark her zaman problem değildir. Uzmanlık gerektiren işlerde bağlama göre farklı kararlar verilmesi gerekir.

Problem, sonucun kalitesini etkileyen kritik kontrollerin yalnız çalışanın hafızasına veya kişisel alışkanlığına bağlı olmasıdır.

SOP burada:

Kişisel çalışma biçimi
↓
Tanımlı minimum süreç
↓
Kontrol noktaları
↓
Karar kuralları
↓
Benzer kalite standardı

dönüşümünü sağlar.

EPA da SOP kullanımını kalite sisteminin bir parçası olarak konumlandırır ve tutarlı uygulamanın personel değişiklikleri sırasında bile süreç kalitesini korumaya yardımcı olabileceğini belirtir.

SOP’un amacı çalışanları robotlaştırmak mı?

Hayır.

Özellikle SEO, CRO, ürün, pazarlama veya yazılım gibi bilgi işlerinde:

Her durumda aynı şeyi yap.

diyen bir SOP çoğu zaman kötü SOP’dur.

İyi standardizasyon:

Normal koşul
→ Standart akış

X durumu oluşursa
→ Alternatif akış

Y riski görülürse
→ Kontrol gerçekleştir

Karar verilemiyorsa
→ Escalate et

mantığıyla çalışır.

Yani amaç insan muhakemesini ortadan kaldırmak değildir.

Amaç hangi noktalarda muhakeme gerektiğini, hangi noktalarda ise minimum standardın değişmemesi gerektiğini ayırmaktır.

Bu yaklaşım SEO stratejisinde kullandığım karar kapıları ve kabul kriterleri mantığıyla da doğrudan ilişkilidir. Bir sonraki aşamaya ne zaman geçileceğinin açık olması, sürecin yalnız yapılacak işler listesinden ibaret kalmasını engeller.

SOP ve standardizasyon arasındaki ilişki nedir?

SOP, standardizasyonun operasyonel araçlarından biridir.

Fakat:

STANDARDIZATION
≠
HER DURUMDA AYNI HAREKET

Standardizasyon daha çok:

Benzer koşullarda aynı kalite seviyesine ulaşmak için hangi minimum yöntem, kontrol ve karar kurallarını korumalıyız?

sorusudur.

Örneğin bir site migration sürecinde bütün projeler aynı değildir.

Ancak şu kontrollerin yapılması projeye göre keyfi biçimde değişmemelidir:

• eski ve yeni URL mapping’in kontrol edilmesi,
• redirect hedeflerinin doğrulanması,
• canonical sinyallerinin kontrol edilmesi,
• sitemap’in yeni URL yapısıyla tutarlı olması,
• kritik internal linklerin eski adreslere gitmemesi,
• önemli URL’lerin HTTP ve indexability durumlarının doğrulanması,
• migration sonrası ölçümün takip edilmesi.

Asıl stratejik kararlar projeye göre değişebilir.

Minimum kalite kontrolü değişmemelidir.

SOP neden bir kalite yönetimi aracıdır?

SOP kavramının tarihsel ve teknik kullanım alanlarının önemli bölümü kalite yönetimi, laboratuvar süreçleri, üretim, sağlık ve regülasyona tabi operasyonlardan gelir.

Bunun nedeni basittir.

Bir süreç kritik hale geldikçe şu soruların cevapları daha önemli olur:

Ne yapılması gerekiyordu?

Kim yapmalıydı?

Hangi yöntem kullanılmalıydı?

Hangi kontrol uygulanmalıydı?

Gerçekte ne yapıldı?

Bir sapma oldu mu?

Çıktı kabul kriterini geçti mi?

ISO 10013 de kalite yönetim sistemlerini destekleyen dokümante edilmiş bilginin organizasyonun kendi ihtiyaçlarına göre geliştirilmesi ve sürdürülmesini ele alır.

Buradaki kritik nokta şudur:

Amaç SOP üretmek değildir. Amaç kontrol edilebilir süreç üretmektir.

ISO’nun süreç yaklaşımında da her sürecin aynı biçimde veya aynı miktarda dokümante edilmesi gerektiği söylenmez. Sürecin karmaşıklığı, kritiklik seviyesi, riskleri ve resmi hesap verebilirlik ihtiyacı ne kadar dokümantasyon gerektiğini etkiler.

SOP’un temel işlevleri nelerdir?

1. Tekrarlanabilirlik

İyi SOP, işi bilen fakat süreci ilk kez uygulayan bir kişinin kritik adımları atlamadan çalışabilmesini sağlamalıdır.

Örneğin:

Sitemap’i kontrol et.

zayıf talimattır.

Çünkü “kontrol et” kelimesi uygulanacak yöntemi tarif etmez.

Daha iyi:

XML sitemap’i aç, HTTP 200 döndürdüğünü doğrula. Sitemap içerisindeki URL’leri crawl export ile karşılaştır. 3xx, 4xx, 5xx, noindex ve canonical olmayan URL’leri ayrı issue olarak işaretle.

Burada işlemin ne olduğu ve beklenen kontrol daha nettir.

2. Traceability: Ne yapıldığını sonradan görebilmek

SOP yalnız gelecekte ne yapılacağını anlatmamalıdır.

Gerektiğinde geçmişte ne yapıldığını da doğrulanabilir hale getirmelidir.

Örneğin bir migration sonrası organik trafik ciddi biçimde düştü.

Şu soruları cevaplamak isteyebiliriz:

Hangi migration SOP versiyonu kullanıldı?

URL mapping'i kim doğruladı?

Redirect QA ne zaman yapıldı?

Hangi crawl export kullanıldı?

Critical URL sample kontrol edildi mi?

Bir deviation kaydedildi mi?

Bu kayıtlar yoksa sorun çıktığında süreç geriye doğru yeniden kurulmaya çalışılır.

3. Quality Assurance

SOP çoğunlukla Quality Assurance, yani kalite güvence tarafında değerlidir.

Basit ayrım:

QA
→ Doğru sonucu üretmeye uygun süreç tasarla

QC
→ Üretilen çıktının kriterleri karşılayıp karşılamadığını kontrol et

Örneğin:

Technical SEO Audit SOP
→ QA

Audit tesliminden önce
final QA checklist
→ QC

İkisi birbirinin alternatifi değildir.

4. Kurumsal hafıza

Bir ekipte önemli operasyon bilgisi çoğu zaman insanların kafasında yaşar.

Örneğin kıdemli bir SEO uzmanı şöyle diyebilir:

Migration sonrası sitemap’i hemen göndermiyorum. Önce şu üç kontrolü yapıyorum.

Bu bilgi yalnız o kişinin zihnindeyse tacit knowledge, yani örtük bilgidir.

Süreç dokümante edildiğinde:

PERSON KNOWLEDGE
↓
DOCUMENTED PROCESS
↓
TEAM KNOWLEDGE
↓
ORGANIZATIONAL MEMORY

haline gelir.

Bu, özellikle ekip büyütürken önemlidir.

5. Accountability

SOP:

Birisi bunu kontrol edecekti.

cümlesini:

SEO Specialist uygulamayı yapar, SEO Lead P0/P1 bulgularını doğrular ve teslim QA onayından sonra tamamlanır.

seviyesine taşır.

Yani sorumluluk isme değil role bağlanır.

SOP, process, policy, work instruction ve checklist aynı şey midir?

Hayır.

Katman	Temel soru
Policy	Hangi ilke ve kurallara göre hareket ediyoruz?
Process	Hangi girdiyi hangi çıktıya dönüştürüyoruz?
SOP / Procedure	Bu süreç organizasyon içinde nasıl yürütülüyor?
Work Instruction	Belirli teknik görev tam olarak nasıl uygulanıyor?
Checklist	Gerekli kontroller tamamlandı mı?
Record	İşlemin gerçekleştirildiğinin kanıtı nedir?

Örneğin SEO tarafında:

PROCESS
Technical SEO Audit

↓

SOP
Audit nasıl yürütülür?

↓

WORK INSTRUCTION
Screaming Frog crawl configuration

↓

CHECKLIST
Teslim öncesi QA

↓

RECORD
Crawl export + issue sheet + approval

Bu terminoloji her organizasyonda birebir aynı olmayabilir.

Önemli olan dosyanın adı değil, hangi problemi çözdüğüdür.

Her iş için SOP yazılmalı mı?

Hayır.

Her işi SOP’a çevirmek sistem kurmak değil, bürokrasi üretmektir.

Ben SOP ihtiyacını şu mental modelle değerlendiririm:

SOP İHTİYACI

≈

Tekrarlanma sıklığı
×
Süreç varyasyonu
×
Hata etkisi
×
Bilgi bağımlılığı
×
Kanıt ihtiyacı

Bu matematiksel bir kalite formülü değildir.

Karar vermeyi kolaylaştıran çerçevedir.

Örneğin:

İş	SOP ihtiyacı
Technical SEO audit	Yüksek
Site migration QA	Çok yüksek
Yeni içerik yayınlama QA	Yüksek
A/B test launch kontrolü	Yüksek
Aylık GSC baseline export	Orta-yüksek
Strateji workshop’u	Daha düşük, framework daha uygun olabilir
Yeni fikir üretme oturumu	Düşük

Özellikle yüksek muhakeme gerektiren yaratıcı işleri 60 maddelik prosedürlere sıkıştırmak genellikle fayda üretmez.

SEO ve CRO operasyonlarında hangi işler SOP için güçlü adaydır?

Berkedalar.com’da anlattığım çalışma alanları açısından SOP kullanımı özellikle tekrar eden ve hata maliyeti yüksek operasyonlarda anlamlıdır.

Technical SEO audit

Minimum crawl, indexability, canonical, sitemap, internal linking ve template kontrollerinin atlanmaması gerekir.

Özellikle büyük e-ticaret sitelerinde URL üretim sistemleri ve crawl davranışları bağlama göre değişse bile inceleme metodunun minimum standardı korunabilir. E-ticaret Technical SEO’da URL space, crawling ve canonicalization arasındaki bağımlılıkları bu nedenle tek tek checklist maddeleri yerine bir sistem olarak ele alıyorum.

Site migration

Migration nadiren yapılabilir fakat hata etkisi son derece yüksektir.

Dolayısıyla:

Düşük frekans
+
Yüksek risk
=
Güçlü SOP adayı

İçerik yayınlama

Bir içerik CMS’e girerken:

• URL,
• title,
• meta description,
• canonical,
• topic,
• internal link,
• görsel alt text,
• schema,
• indexability

gibi tekrar eden kontroller varsa bunların her editörün hafızasına bırakılması gereksiz varyasyon üretir.

Usability testing

Kullanıcı testi tamamen script’e bağlanmamalıdır. Moderatörün takip soruları ve gözlemleri muhakeme gerektirir.

Ama:

• katılımcı kriteri,
• test environment,
• consent,
• recording,
• task preparation,
• observation formatı,
• evidence storage

standardize edilebilir.

Usability testing sürecinde katılımcı seçimi, görev tasarımı ve gözlem mantığını ayrıca ele alıyorum.

İyi bir SOP nasıl yazılır?

SOP yazmaya doküman açarak başlamamak gerekir.

Önce süreç anlaşılmalıdır.

Çünkü:

Kötü süreci iyi dokümante etmek, yalnızca kötü sürecin daha istikrarlı uygulanmasını sağlar.

Önce mevcut süreç haritalanabilir:

TRIGGER
↓
INPUT
↓
ACTIVITY
↓
DECISION
↓
HANDOFF
↓
CONTROL
↓
OUTPUT

Ardından SOP yazılır.

Ben dijital operasyonlarda şu yapıyı kullanırım:

DOCUMENT CONTROL
↓
PURPOSE
↓
SCOPE
↓
ROLES
↓
PRECONDITIONS / INPUTS
↓
PROCEDURE
↓
DECISION RULES
↓
QUALITY CONTROLS
↓
OUTPUT
↓
ACCEPTANCE CRITERIA
↓
RECORDS
↓
EXCEPTIONS / ESCALATION
↓
REVISION HISTORY

1. Document Control

SOP’un hangi sürümünün geçerli olduğu bilinmiyorsa prosedürün güvenilirliği ciddi biçimde azalır.

Minimum metadata:

SOP ID
Title
Version
Owner
Author
Reviewer
Approver
Effective Date
Last Review
Next Review
Status

Örneğin:

SOP-SEO-003
Technical SEO Audit
v1.2
Owner: SEO Lead
Status: Active

2. Purpose: Bu SOP neden var?

Zayıf:

Bu SOP SEO auditini anlatır.

Daha iyi:

Bu prosedürün amacı yeni müşteri web sitelerinde gerçekleştirilen teknik SEO auditlerinin minimum kapsamını, uygulama yöntemini, karar kurallarını, kalite kontrollerini ve teslim kriterlerini standardize etmektir.

Purpose dokümanın konusunu değil, kontrol etmek istediğimiz operasyonel sonucu anlatmalıdır.

3. Scope: Nerede başlar, nerede biter?

Örneğin:

START
Gerekli erişimlerin teslim alınması

↓

END
Audit bulgularının QA'dan geçip
proje sistemine aktarılması

Content strategy veya backlink analysis kapsam dışındaysa açıkça belirtilir.

Scope olmazsa SOP zamanla küçük bir şirket anayasasına dönüşür.

4. Roles & Responsibilities

Örneğin:

Rol	Sorumluluk
SEO Specialist	Audit’i gerçekleştirir ve kanıtları kaydeder.
SEO Lead	Kritik bulguları ve öncelik seviyesini doğrular.
Developer	Onaylanan teknik değişiklikleri uygular.
Project Manager	Owner, deadline ve takip durumunu yönetir.

5. Preconditions ve Inputs

Technical SEO audit başlamadan önce:

Domain
GSC access
GA4 access
Sitemap
CMS / platform bilgisi
Crawl permission
Hedef pazar
Migration geçmişi

gibi girdiler gerekebilir.

Kritik input eksikken çalışan prosedürün çıktısı doğal olarak değişir.

6. Procedure

Talimatı mümkün olduğunca şu yapıyla yazmak faydalıdır:

ACTION
+
OBJECT
+
CONDITION
+
EXPECTED RESULT

Örneğin:

XML sitemap’i crawl et ve sitemap içerisindeki URL’lerin HTTP status, indexability ve canonical durumlarını doğrula. 3xx, 4xx, 5xx, noindex veya başka URL’ye canonical veren girdileri ayrı issue grubuna aktar.

7. Decision Rules

Bence modern bilgi işlerinde SOP’un en değerli bölümlerinden biri burasıdır.

Çünkü çalışanı yalnız işlem yapan kişiden karar sistemi uygulayan kişiye dönüştürür.

Money page yanlışlıkla noindex ise
→ P0

Canonical target 4xx ise
→ P0/P1 bağlama göre doğrula

Kasıtlı canonicalized URL ise
→ Issue açma
→ Gerekçeyi kaydet

Karar belirsizse
→ SEO Lead'e escalate et

P0, P1, P2 önceliklendirmesini ve karar kapılarını strateji yazısında daha geniş bağlamda ele alıyorum.

8. Acceptance Criteria ve Definition of Done

“Yapıldı” kabul kriteri değildir.

Örneğin:

Sitemap kontrol edildi.

yerine:

Sitemap HTTP 200 dönüyor, yalnız amaçlanan canonical ve indexable URL’leri içeriyor ve 3xx/4xx/5xx URL bulunmuyor.

daha güçlüdür.

Buradaki ayrım:

ACTION COMPLETED
≠
EXPECTED RESULT ACHIEVED

şeklindedir.

9. Records ve Evidence

İş yapıldıktan sonra geriye ne kalacak?

SEO audit örneğinde:

Crawl export
GSC export
Issue sheet
Screenshot
Log sample
Ticket
QA approval

kayıt olabilir.

Bu katman olmadan SOP yalnız talimat sistemidir.

Evidence eklendiğinde izlenebilir süreç haline gelir.

10. Exceptions ve Escalation

Gerçek süreçler her zaman ideal akışı takip etmez.

Örneğin:

Developer staging ortamına erişim veremiyor.

veya:

Canonical davranışı SPA nedeniyle standart crawl’da doğrulanamıyor.

olabilir.

SOP burada:

İşi yine de tamamlandı say

dememelidir.

Daha doğru:

Exception
↓
Reason
↓
Impact
↓
Escalation
↓
Alternative control
↓
Record

SOP deviation nedir?

SOP deviation, operasyonun onaylanmış prosedürden farklı biçimde yürütülmesidir.

Regülasyona tabi sistemlerde deviation formal biçimde kaydedilebilir ve yetkilendirilebilir.

Dijital operasyonlarda daha hafif model yeterli olabilir:

Expected Procedure
↓
Deviation
↓
Why?
↓
Risk / Impact
↓
What did we do?
↓
Should SOP change?

Buradaki son soru özellikle değerlidir.

Aynı deviation tekrar tekrar oluşuyorsa:

Çalışanlar SOP’a uymuyor.

demeden önce:

SOP gerçek işi yanlış mı modelliyor?

diye bakmak gerekir.

SOP lifecycle nasıl çalışır?

SOP yazıldıktan sonra süreç bitmez.

PROCESS ANALYSIS
↓
DRAFT
↓
REVIEW
↓
VALIDATION
↓
APPROVAL
↓
TRAINING
↓
USE
↓
MONITORING
↓
FEEDBACK / DEVIATION
↓
REVISION
↓
NEW VERSION

PLOS Computational Biology’de yayımlanan SOP yazımı çalışması da prosedürün yalnız hazırlanmasını değil validation, approval, implementation ve monitoring adımlarını birlikte ele alır.

Bu yüzden:

seo-audit-sop-final.docx
seo-audit-sop-final-2.docx
seo-audit-sop-son-final.docx

şeklindeki insanlığın klasik doküman yönetim sistemi yerine revision history kullanılmalıdır.

Örneğin:

SOP-SEO-003

v1.0
Initial release

v1.1
Sitemap QA güncellendi

v1.2
JavaScript rendering kontrolü eklendi

v2.0
Audit workflow yeniden tasarlandı

Work as Imagined ve Work as Done

Bir süreci dokümante ederken en tehlikeli hatalardan biri yalnız yöneticinin sürecin nasıl çalıştığını düşündüğüne bakmaktır.

Bir tarafta:

WORK AS IMAGINED
"İş böyle yapılıyor."

vardır.

Diğer tarafta:

WORK AS DONE
"İnsanlar gerçekte böyle yapıyor."

vardır.

Bu ikisi aynı olmayabilir.

Örneğin SOP:

Bütün P1 bulgular SEO Lead tarafından incelenir.

diyebilir.

Gerçekte ekip:

Yoğunluk olduğunda yalnız P0’ları gönderiyoruz.

diyorsa kağıt üzerindeki prosedür artık gerçek sistemi anlatmıyordur.

Bu yüzden SOP işi gerçekten yapan kişilerin katılımıyla hazırlanmalıdır.

SOP ile checklist arasındaki en önemli fark nedir?

Checklist hatırlatma aracıdır.

SOP süreç modelidir.

Checklist:

□ Sitemap
□ Canonical
□ Robots
□ Internal links
□ Indexability

diyebilir.

SOP ise:

Sitemap'te non-canonical URL bulunursa
↓
URL sample doğrula
↓
Pattern mı tekil hata mı belirle
↓
Owner / intent kontrol et
↓
Issue priority belirle
↓
Evidence kaydet

der.

Bu ayrım önemlidir çünkü dijital operasyonların büyük bölümü yalnız kontrol değil karar gerektirir.

Pratik SOP şablonu

SOP ID:
Title:
Version:
Owner:
Status:
Effective Date:

1. PURPOSE
Bu prosedür neden var?

2. SCOPE
Nerede başlıyor?
Nerede bitiyor?
Neler kapsam dışı?

3. ROLES
Kim ne yapıyor?

4. PRECONDITIONS / INPUTS
Başlamadan önce ne gerekli?

5. PROCEDURE
İş hangi sırayla yapılır?

6. DECISION RULES
X olursa ne olur?
Y olursa ne olur?

7. QUALITY CONTROLS
Hangi noktalarda kontrol var?

8. OUTPUT
Sürecin teslimatı nedir?

9. ACCEPTANCE CRITERIA
Hangi koşulda tamamlanmış sayılır?

10. RECORDS
Hangi evidence saklanır?

11. EXCEPTIONS / ESCALATION
Standart akış çalışmazsa ne olur?

12. REFERENCES
Hangi sistem veya dokümanlarla ilişkili?

13. REVISION HISTORY
Ne değişti ve neden?

SOP yazarken yapılan yaygın hatalar

Her şeyi SOP yapmak

Risk ve tekrar düşükse prosedürün bakım maliyeti faydasından yüksek olabilir.

Mevcut kötü süreci aynen dokümante etmek

Önce process analysis, sonra SOP.

Yalnız mutlu yolu yazmak

Gerçek süreçler exception ve decision point içerir.

“Kontrol et” gibi belirsiz talimatlar kullanmak

Neyin, nasıl ve hangi kabul kriterine göre kontrol edildiği tanımlanmalıdır.

Owner belirlememek

Süreç herkesin sorumluluğundaysa çoğu zaman kimsenin sorumluluğunda değildir.

Evidence tanımlamamak

İşin yapıldığı daha sonra doğrulanamıyorsa traceability zayıftır.

SOP’u hiç güncellememek

Platform, tool veya süreç değişirken SOP değişmiyorsa çalışanlar ya eski yöntemi uygular ya da SOP’u görmezden gelmeye başlar.

SOP’u düşünmenin yerine koymak

Bilgi işlerinde iyi prosedür karar vermeyi destekler. Karar vermeyi yok etmeye çalışmaz.

Berkedalar.com bağlamında SOP neden önemli?

SEO, CRO ve Search Systems gibi alanlarda problem çoğu zaman bilgi eksikliğinden ibaret değildir.

Bilgiyi tekrar edilebilir operasyona dönüştürme problemi de vardır.

Bir uzman:

Migration nasıl yapılır biliyorum.

diyebilir.

Başka bir seviye ise:

Migration sürecini hangi kontrollerle, hangi evidence ile ve hangi Definition of Done altında yöneteceğimizi biliyoruz.

demektir.

Birincisi expertise’tir.

İkincisi operational maturity’dir.

Bu yüzden SOP’u yalnız kurumsal bürokrasi veya onboarding dokümanı gibi görmüyorum.

SOP, uzmanlığı tekrar edilebilir iş sistemine dönüştürmenin araçlarından biridir.

Sonuç: SOP’un ürünü doküman değildir

SOP’u:

Bir işin nasıl yapılacağını anlatan doküman.

diye tanımlamak başlangıç için yeterlidir.

Fakat operasyonel açıdan daha kullanışlı tanım şudur:

Standard Operating Procedure; tekrar eden bir operasyonun kapsamını, rollerini, girdilerini, uygulama adımlarını, karar kurallarını, kalite kontrollerini, kabul kriterlerini, kayıtlarını, sapmalarını ve revizyon mekanizmasını tanımlayan kontrollü süreç dokümantasyonudur.

Amaç:

Kişiye bağımlı iş
↓
Tanımlı süreç
↓
Tekrarlanabilir uygulama
↓
Kontrol edilebilir kalite
↓
İzlenebilir sonuç
↓
Ölçülebilir süreç
↓
Sürekli iyileştirme

dönüşümünü sağlamaktır.

Bu yüzden SOP’un başarısını sayfa sayısıyla ölçmek anlamsızdır.

Daha doğru sorular:

• Farklı insanlar süreci benzer kalite seviyesinde uygulayabiliyor mu?
• Kritik adımlar atlanıyor mu?
• Karar noktaları açık mı?
• Bir hata olduğunda ne yapıldığı geriye doğru görülebiliyor mu?
• Sürecin tamamlandığını gösteren acceptance criteria var mı?
• Gerçek çalışma biçimi değiştiğinde SOP da güncelleniyor mu?

Bu soruların cevabı evetse SOP işini yapıyordur.

Çünkü SOP’un ürünü doküman değil, öngörülebilir ve geliştirilebilir süreçtir.

Sık Sorulan Sorular

SOP nedir?

SOP, Standard Operating Procedure ifadesinin kısaltmasıdır. Tekrar eden bir operasyonun kapsamını, sorumluluklarını, yöntemini, kontrol noktalarını ve gerekli kayıtlarını tanımlayan standart çalışma prosedürüdür.

SOP neden kullanılır?

Süreç varyasyonunu azaltmak, kritik işlerin kişilerin hafızasına bağımlılığını düşürmek, benzer kalite standardını korumak, eğitim ve bilgi aktarımını kolaylaştırmak ve yapılan işlemleri izlenebilir hale getirmek için kullanılabilir.

Checklist ile SOP arasındaki fark nedir?

Checklist belirli kontrollerin tamamlanıp tamamlanmadığını hatırlatır. SOP ise sürecin kapsamını, rollerini, adımlarını, karar kurallarını, istisnalarını ve kabul kriterlerini daha geniş biçimde tanımlar.

Her süreç için SOP gerekli midir?

Hayır. Sürecin tekrar sıklığı, karmaşıklığı, hata etkisi, bilgi bağımlılığı ve kanıt ihtiyacı değerlendirilmelidir. Düşük riskli ve yüksek oranda yaratıcı işler için daha hafif framework veya checklist yeterli olabilir.

SOP kim tarafından yazılmalıdır?

SOP geliştirme sürecine işi gerçekten uygulayan subject-matter expert’lerin dahil olması gerekir. Yönetim veya süreç owner’ı review ve approval görevini üstlenebilir; ancak gerçek operasyonu bilmeden yalnız masa başında yazılan SOP’lar Work as Done ile kolayca ayrışabilir.

SOP ne sıklıkla güncellenmelidir?

Evrensel tek bir süre yoktur. Tool, mevzuat, organizasyon, süreç veya kalite gereksinimleri değiştiğinde SOP gözden geçirilmelidir. Kritik prosedürlerde ayrıca periyodik review tarihi tanımlamak faydalıdır.

SOP SEO ve CRO ekiplerinde kullanılabilir mi?

Evet. Technical SEO audit, migration QA, içerik yayınlama, analytics implementation, usability testing hazırlığı, experiment launch QA ve raporlama gibi tekrar eden operasyonlar SOP için güçlü adaylardır.

Kaynaklar

1. U.S. Environmental Protection Agency, Guidance for Preparing Standard Operating Procedures, EPA QA/G-6.
2. International Organization for Standardization, The Process Approach in ISO 9001.
3. ISO 10013:2021, Quality management systems – Guidance for documented information.
4. Hollmann S. et al. (2020), Ten simple rules on how to write a standard operating procedure, PLOS Computational Biology.
5. U.S. Food and Drug Administration, Good Laboratory Practice regulations and SOP guidance.