Süreç dokümantasyonu şablonu: Bir süreç uygulanacak şekilde nasıl belgelenir (2026)

Süreç dokümantasyonu şablonu, bir süreç tanımının içine yerleştirildiği sabit iskelettir: kimlik numarası, sürüm, sahip ve gözden geçirme tarihini içeren bir üst bilgi; ardından amaç ve sonuç, tetikleyici ve bitiş durumu, kapsam, roller, aşamaların sırasıyla kimin neyi kime devrettiği ve her aşamanın geride ne bıraktığı, istisnalar, ölçütler, ilgili SOP'ler ve bir revizyon geçmişi. Biçim, kopyalayabileceğiniz bir şablon, uygulamalı bir örnek, belgelenmiş bir sürecin uygulanmamasının üç nedeni ve her birinin çözümü, süreç belgesinin ve anlatım kaydının Teams, Zoom, Google Workspace ve Slack'te nerede durduğu — ayrıca sürecin ve her anlatımının her üye için kendi dilinde nasıl okunabilir kaldığı.

The Mind.com Team

  • Süreç belgesi, sahiplerinin eklendiği haritadır: tetikleyici, bitiş durumu, sırayla aşamalar, kimin neyi kime devrettiği ve yol tıkandığında kimin karar verdiği.
  • Bulunduğunda, doğru olduğunda ve duyurulduğunda uygulanır; Teams, Zoom, Google Workspace ve Slack'te ise tek dilli bir dosyadır ve elle yeniden yazılır.
  • InterMIND, süreci ve süreç üzerinden geçme oturumlarının tümünü her üyenin kendi dilinde tutar; bu araçların yerine geçmez, yanlarında durur. Misafirler bağlantıyla ücretsiz ve hesapsız katılır; yalnızca aktif üyeler için ödeme yaparsınız.
Süreç dokümantasyonu şablonu: Bir süreç uygulanacak şekilde nasıl belgelenir (2026)

Süreç dokümantasyonu şablonu: bir süreç nasıl belgelenir ki uygulansın (2026)

Süreç dokümantasyonu, bir işin kuruluşunuzda onu başlatan olaydan bitiren sonuca kadar nasıl aktığının yazılı tarifidir: sırayla aşamalar, her birinin sahibi olan rol, bir rolden diğerine ne geçtiği, her aşamanın geride ne bıraktığı ve normal yol tıkandığında ne olduğu. Süreç dokümantasyonu şablonu ise bu sözcüklerin içine yerleştiği sabit iskelettir. Böylece onuncu süreç ilki gibi okunur ve birini okumuş bir kişi hepsinde yolunu bulabilir.

Çoğu süreç zaten bir yerde belgelenmiştir: iki yıl önceki bir atölyeden kalma bir diyagramda, kimsenin açmadığı bir wiki sayfasında, işi en baştan beri yapan tek kişinin kafasında. Sorun nadiren belgenin var olmamasıdır. Sorun belgenin uygulanmamasıdır ve bunun üç nedeni her kuruluşta aynıdır. Bu rehber önce işin zanaatını ele alır: süreç belgesi nedir, ne değildir, standart format, kopyalayabileceğiniz bir şablon ve çalışılmış bir örnek. Ardından üç nedeni ve her birinin çözümünü, belgenin ve üzerinden geçme oturumunun ekibinizin zaten kullandığı araçlarda nerede durduğunu, ve belgeyi başka bir dilde okuyan meslektaşın ne elde ettiğini anlatır. Çünkü bir süreç belgesi, yeni bir müşteri temsilcisinin, yeni bir hemşirenin ya da yeni bir distribütör çalışanının bir şeyi sıradaki kişiye devretmesi gereken ve o kişinin kim olduğunu bilmediği sabahta sınanır.

Süreç belgesi nedir, ne değildir

Üç belge, işlerin süreç düzeyinde nasıl yapıldığını anlatır. Bunlar sıklıkla birbirleriyle ve altlarındaki prosedürlerle karıştırılır:

Yanıtladığı soruAyrıntı düzeyiBir satır nasıl görünürKim okur
Süreç haritasıAşamalar nelerdir ve nasıl bağlanırBir diyagram: kutular, oklar, rol başına kulvarlarAlım → Ön değerlendirme → Çözüm → Kapanışİşi tasarlayanlar; yeni biri, şekli görmek için bir kez
Süreç belgesiHer aşamanın sahibi kim, aralarında ne geçer, her aşama geride ne bırakır, sorunsuz akışın dışında ne yapılırSüreç başına bir sayfa metin: aşamalar, devirler, istisnalar, ölçüler"2. Ön değerlendirme — hizmet lideri — girdi: kayda geçen şikâyet — çıktı: kayıtta bir kategori ve bir sahip — kime: temsilci — en geç: bir iş günü"Sürece katılan herkes; sahibi, her gözden geçirmede
SOPBir aşama, bir rol tarafından adım adım nasıl yapılırBir prosedür, bir rol"2.3 Hizmet lideri, şikâyeti kayıttaki ürün grubuna göre bir temsilciye atar"O işi yapan kişi, alışkanlık olana kadar her seferinde

Harita resimdir; süreç belgesi resmi kullanılabilir kılan metindir; SOP'ler her kutunun altındaki ayrıntıdır. Ayrım uzunluğu belirler: her adımın nasıl tıklandığını anlatan bir süreç belgesi kimsenin okumadığı bir kılavuza dönüşür, metni olmayan bir süreç haritası ise herkesin başka yorumladığı bir resimdir. SOP'nin kendisi, şablonu ve gözden geçirme döngüsü SOP template ve how to write an SOP yazılarında anlatılıyor. Bu rehber onların bir üst düzeyiyle ilgilenir: SOP'lerin nerede gerektiğini ve kimin neyi kime devrettiğini söyleyen düzey.

Süreç belgesi ayrıca işin genellikle nasıl yapıldığının tarifi de değildir. Üzerinde anlaşılmış yoldur; bir sahibi, bir sürümü ve bir gözden geçirme tarihi vardır. Bu yüzden kimsenin uymadığı bir aşama, metinde bırakılacak bir cümle değil, değiştirilecek bir aşama ya da yapılacak bir konuşmadır.

Neler eklenmeli: standart format

Kullanılabilir bir süreç belgesi bir başlık bölümü ve sekiz bölüm içerir. İnternetteki çoğu şablon amacı, adımları ve bir diyagramı içerir ve orada durur. Çoğu süreç belgesinin bir kez okunup bir daha açılmamasının nedeni budur:

Başlık bölümü: belgenin kimliği, tek satırda beş alan: kendisine atıf yapılabilecek bir kimlik ("PR-HR-02"), bir sürüm ("v1.3"), sahip (bir departman değil, sürecin tamamından sorumlu, adı belli tek bir kişi), yürürlük tarihi ve bir sonraki gözden geçirme tarihi. Gözden geçirme tarihi olmayan bir süreç, bir şeyler ters gittiğinde gözden geçirilir.

  1. Amaç ve sonuç. Bir ya da iki cümle: bu süreç neyi, kime sunar ve iyi sonuç neye benzer; elinizde varsa bir sayıyla. "Yeni çalışanın ilk gün hesapları, ekipmanı, bir planı ve adı belli bir rehber arkadaşı vardır; 30. güne kadar da 30 günlük bir değerlendirmesi yapılır."
  2. Tetikleyici ve bitiş durumu. Süreci başlatan olay ve bitiren sonuç. "İmzalı sözleşme İK klasörüne düştüğünde başlar; 30 günlük değerlendirme kaydedildiğinde biter." Bu iki cümle arasındaki her şey süreçtir, dışındaki her şey başka bir belgedir. Sürecin net bir sonu yoksa iki süreçtir.
  3. Kapsam. Bu sürecin ne zaman geçerli olduğu ve ne zaman olmadığı; komşu süreçler kimliğiyle anılarak. "Bizimle sözleşmeli çalışanlar, her ülkede. Hariç: bağımsız yükleniciler (PR-HR-04); hariç: şirket içi transferler (PR-HR-06)."
  4. Roller. Aşamalarda yer alan her rol ve neyin sahibi olduğu; isimler değil roller yazılır, böylece belge bir işe alımdan sonra da geçerli kalır. Bunlardan biri, hiç kimsenin varsayılan olarak sahiplenmediği devirler dahil, akışın tamamından sorumlu olan süreç sahibidir.
  5. Aşamalar ve devirler. Belgenin kalbi: sırayla aşamalar; her birinde işi yapan rol, ne geldiği (girdi), ne çıktığı ve nerede kaydedildiği (çıktı), kime gittiği ve süre sınırı. Devir açıkça yazılır ("kime: BT, −5. günde") çünkü süreçler devirde bozulur: iki taraf da diğerinin elinde olduğunu sanır.
  6. İstisnalar ve yükseltme. Sorunsuz akışın dışındaki dallar: izin gecikirse, kredi kontrolü başarısız olursa, sahip yerinde değilse ne olur. Her istisna karar verecek bir rol ya da kişi belirtir, asla "birine sor" demez. Son satır kaçırdıklarınızı kapsar: "Burada ele alınmayan her şey: süreç sahibi karar verir ve konu bir sonraki gözden geçirmede gündeme getirilir."
  7. Ölçüler. Sahibin izlediği iki ya da üç sayı: tetikleyiciden bitiş durumuna döngü süresi, aylık vaka sayısı, istisnaya düşenlerin oranı. Bir gösterge paneli değil; bir kişi şikâyet etmeden önce sürecin kaydığını sahibine söyleyen sayılar.
  8. İlgili belgeler ve revizyon geçmişi. Her aşamanın altındaki SOP'ler, sürecin uyguladığı politika, haritaya bağlantı; ardından her sürüm için bir satır: tarih, ne değişti, kim onayladı. Geçmiş, aynı hatanın yeni bir sürüm numarasıyla yeniden ortaya çıkmasını önler.

Dışarıda kalanlar: her kuralın gerekçesi (politikanın işi), bir aşamanın tıklama tıklama ayrıntısı (SOP'nin işi) ve bir kişinin üzerine eylem yapamayacağı her şey. "Sorunsuz bir oryantasyona değer veriyoruz" bir duygudur, bir aşama değildir.

Bir süreç nasıl belgelenir ki uygulansın

Uygulanmayan hemen her süreç belgesini üç neden açıklar ve her birinin çözümü, sonradan gelecek bir denetime değil, yazım işine aittir.

Birinci neden: süreci işlediği gibi değil, tasarlandığı gibi anlatır. Belge, bir atölyede işi yöneten kişiler tarafından yazılmıştır; işi yapanların ise farklı bir sürümü vardır: yanda bir hesap tablosu ve 3. aşamada aranan bir meslektaşla. Çözüm, yazmadan önce süreci kanıttan haritalamaktır. Üç gerçek vakayı tetikleyiciden bitiş durumuna kadar izleyin ve gerçekte olanı yazın: e-postalar, mesajlar, formlar, beklemeler. Süreç bir grup sohbetinde yaşıyorsa (WhatsApp'a düşen distribütör siparişleri, bir Telegram grubunda kararlaştırılan vardiya değişimleri), kanıt sohbettir ve üzerinden geçme, onun geçmişiyle başlar. Export chat'in size ne verdiği ve nerede bittiği how to export a WhatsApp chat yazısında anlatılıyor. Üç vakanın ayrıştığı yer belgenin var olma nedenidir; her fark için, bunun metinde düzeltilecek bir aşama mı yoksa ekiple yapılacak bir konuşma mı olduğuna karar verin.

İkinci neden: güncel sürümü kimse bulamıyor. Belge kırk başka belgeyle bir klasördedir, bir kopyası birinin masaüstündedir, üçüncü bir sürüm wiki'dedir ve salı sabahı ona ihtiyacı olan kişi bir meslektaşına sorar. Çözüm, ekibin zaten okuduğu yerde, başlık bölümü görünür şekilde yayımlamaktır. Tek bir yer, önce güncel sürüm, en üstte sahibinin adı ve gözden geçirme tarihi; böylece "bu hâlâ doğru mu?" sorusunu etrafa sormak yerine başlık yanıtlar. Aşamalar roller arası devirler olarak yazılır; her kişi kendi aşamasını ve yanındaki iki aşamayı bir dakikadan kısa sürede bulur.

Üçüncü neden: değişti ve aşaması değişenlere hiç söylenmedi. Bir gözden geçirme kredi kontrolünü toplamadan önceye aldı ya da yer değiştiren çalışanlar için bir adım ekledi ve belge güncellendi; ama depo ekibi ve işe alım yöneticileri eskiden yaptıklarını yapmaya devam etti. Çözüm, süreci onu yürütenlerle birlikte baştan sona gözden geçirmek ve her değişikliği değişen satırlarla duyurmaktır. Üzerinden geçme bir toplantıdır: sahip ve her rolden bir kişi, herkesin ekranında güncel sürüm, her aşama onu yapan kişi tarafından yüksek sesle okunur, her devir iki tarafça da onaylanır. Üzerinden geçmenin değiştirdiği şey geçmişte tek satırla yeni bir sürüm olur. Değişen üç satır, aşaması etkilenen kişilere, zaten okudukları yerde, aynı gün gider. Bir aşamayı değil bir kuralı değiştiren karar, girişte süreç kimliğiyle birlikte decision log kaydına da girer.

Sıra şöyledir: net bir başlangıcı ve bitişi olan tek bir süreç seçin; üç gerçek vakayı izleyin; önce aşamaları şablonda, devirler açık olacak şekilde taslak olarak yazın; istisnaları vakaların gösterdiğinden doldurun; her rolden bir kişiyle üzerinden geçin; başlık bölümünde sahip ve gözden geçirme tarihiyle ekibin okuduğu yerde yayımlayın; gözden geçirme tarihini takvime koyun. Bundan çıkan belge, doğru, bulunabilir ve duyurulmuş olduğu için uygulanır; bu üç özelliği tek başına şablon veremez.

Bir süreç dokümantasyonu şablonu

[Süreç kimliği] — [Süreç adı]
Sürüm: [n.n] · Sahip: [ad, rol] · Yürürlük: [tarih] · Sonraki gözden geçirme: [tarih]

1. Amaç ve sonuç
[Bir ya da iki cümle: bu süreç neyi, kime sunar ve iyi sonuç neye benzer; elinizde varsa bir sayıyla.]

2. Tetikleyici ve bitiş durumu
Başlar: [olay] · Biter: [artık var olan sonuç]

3. Kapsam
Kapsar: [vakalar, lokasyonlar, müşteriler, ülkeler] · Kapsamaz: [başka bir sürecin ele aldığı şey, kimliğiyle]

4. Roller
Süreç sahibi: [akışın tamamından sorumlu tek kişi]
[Rol] — [bu süreçte sahip olduğu şey]
[Rol] — [bu süreçte sahip olduğu şey]

5. Aşamalar ve devirler
5.1 [Aşama] — [rol] — girdi: [gelen şey] — çıktı: [çıkan şey, nerede kaydedildiği] — kime: [sonraki rol] — en geç: [süre sınırı]
5.2 [Aşama] — [rol] — girdi: … — çıktı: … — kime: … — en geç: …
5.3 [Aşama] — [rol] — girdi: … — çıktı: … — kime: … — en geç: …

6. İstisnalar ve yükseltme
[Koşul] olursa: [ne olur, kim karar verir]
[Koşul] olursa: [ne olur, kim karar verir]
Burada ele alınmayan her şey: [rol] karar verir; konu bir sonraki gözden geçirmede gündeme getirilir.

7. Ölçüler
[Sahibin izlediği iki ya da üç sayı (döngü süresi, aylık vaka sayısı, istisnaya düşenlerin oranı) ve nerede okundukları.]

8. İlgili belgeler ve revizyon geçmişi
SOP'ler: [kimlikler, gerekli olan her aşama için bir tane] · Uyguladığı: [politika] · Harita: [diyagrama bağlantı]
v[n.n] — [tarih] — [ne değişti] — onaylayan: [ad]
v[n.n] — [tarih] — [ne değişti] — onaylayan: [ad]

Şablon kalın etiketli düz metindir; bu yüzden yeniden biçimlendirmeye gerek kalmadan bir Word dosyasına, bir Google Doc'a, bir wiki sayfasına, bir Slack canvas'ına ya da bir sohbet notuna yapıştırılabilir. En sık boş bırakılan iki bölüm devirler ("kime, ne zamana kadar") ve gözden geçirme tarihidir; bir yıl sonra sürecin hâlâ belgenin söylediği gibi yürüyüp yürümeyeceğini bu ikisi belirler.

Çalışılmış bir örnek: yeni bir çalışanın oryantasyonu, imzalı sözleşmeden 30. güne

Üç ülkede çalışanı olan altmış kişilik bir şirket; süreç dört rolü kapsar ve 30 günlük değerlendirme kaydedildiğinde biter.

PR-HR-02 — Yeni çalışan oryantasyonu
Sürüm: 1.3 · Sahip: Operasyon müdürü, Inés M. · Yürürlük: 1 Eki 2026 · Sonraki gözden geçirme: 1 Nis 2027

1. Amaç ve sonuç — Yeni çalışanın, hangi ülkede başlarsa başlasın, ilk gün çalışan hesapları, ekipmanı, ilk ay planı ve adı belli bir rehber arkadaşı vardır; 30. güne kadar da kaydedilmiş bir 30 günlük değerlendirmesi yapılır.
2. Tetikleyici ve bitiş durumu — Başlar: imzalı sözleşme İK klasörüne düştüğünde. Biter: 30 günlük değerlendirme çalışanın dosyasına kaydedildiğinde.
3. Kapsam — Bizimle sözleşmeli çalışanlar, her ülkede, ofiste ya da uzaktan. Hariç: bağımsız yükleniciler (PR-HR-04); şirket içi transferler (PR-HR-06).
4. Roller — Süreç sahibi: operasyon müdürü. İK: dosya, belgeler, bordro, karşılama paketi. BT: hesaplar, ekipman, erişim. İşe alım yöneticisi: plan, rehber arkadaş, düzenli görüşmeler. Finans: bordro kurulumu.

5. Aşamalar ve devirler
5.1 Dosyayı açma — İK — girdi: imzalı sözleşme — çıktı: başlangıç tarihi, ülke, yönetici ve dil bilgisiyle oryantasyon kaydı; çalışanın dilinde gönderilen karşılama paketi — kime: BT ve işe alım yöneticisi — en geç: imzadan sonra iki iş günü
5.2 Hesaplar ve ekipman — BT — girdi: kayıt — çıktı: oluşturulan hesaplar, çalışanın adresine gönderilen dizüstü bilgisayar, rol profiline göre erişim; kayıtta onay — kime: İK — en geç: başlangıç tarihinden beş iş günü önce
5.3 Belgeler ve bordro — İK, ardından finans — girdi: kayıt, çalışanın belgeleri (ülkenin gerektirdiği yerde izin veya tescil) — çıktı: bordroda çalışan, dosyada belgeler — kime: işe alım yöneticisi — en geç: başlangıç tarihi
5.4 İlk ayın planlanması — işe alım yöneticisi — girdi: kayıt — çıktı: dosyada 30 günlük plan, adı belli bir rehber arkadaş, çalışanın takviminde ilk hafta, ekiple ayarlanmış karşılama görüşmesi — kime: çalışan, ilk gün — en geç: başlangıçtan önceki gün
5.5 İlk gün — işe alım yöneticisi ve rehber arkadaş — girdi: plan — çıktı: yapılan karşılama görüşmesi, üzerinden geçilen plan, çalışanın açık soruları ekibin kanalına kaydedilmiş — kime: çalışan — en geç: ilk günün sonu
5.6 Düzenli görüşmeler — işe alım yöneticisi — girdi: plan, kaydedilen sorular — çıktı: 7. gün ve 30. gün görüşmeleri, dosyaya kaydedilen 30 günlük değerlendirme — kime: İK, kaydı kapatmak için — en geç: 30. gün

6. İstisnalar — İzin veya tescil başlangıç tarihine kadar çıkmadıysa: çalışan, yöneticinin bunsuz yapılabilir diye işaretlediği görevlerle başlar; takibi İK yürütür ve tarih kayda girer. Dizüstü bilgisayar −2. güne kadar teslim edilmediyse: BT, ofis stokundan geçici bir cihaz gönderir; operasyon müdürüne aynı gün haber verilir. Daha önce işe alım yapmadığımız bir ülkede çalışan: 5.3 aşaması durur; operasyon müdürü üç iş günü içinde employer-of-record yoluna karar verir (PR-HR-05).
7. Ölçüler — İmzadan hesapların hazır olmasına kadar geçen iş günü (hedef ≤ 7); 30. güne kadar 30 günlük değerlendirmesi kaydedilmiş çalışanların oranı (hedef %100); ilk haftada kaydedilen sorular, hangi aşamanın bunları üretmeye devam ettiğini görmek için üç aylık gözden geçirmede okunur.
8. İlgili belgeler — SOP-IT-03 "Yeni hesaplar ve erişim"; SOP-HR-08 "Ülkeye göre bordro kurulumu"; Oryantasyon politikası §2; harita: İK klasöründeki kulvar diyagramı.
v1.3 — 1 Eki 2026 — karşılama paketi artık çalışanın dilinde gönderiliyor; 7. gün görüşmesi eklendi — onaylayan: Inés M.
v1.2 — 3 Haz 2026 — iki geç teslimattan sonra dizüstü bilgisayar gönderimi başlangıçtan beş gün öncesine alındı — onaylayan: Inés M.

Örneğin ne yaptığına dikkat edin. Her aşama rolü, neyin geldiğini, neyin çıktığını ve nerede kaydedildiğini, sonra kime gittiğini ve ne zamana kadar gideceğini belirtir. Böylece gerçekleşmeyen bir devir, ilk günde bir sürpriz olarak değil, kayıtta bir boşluk olarak görünür. Her istisna kimin karar verdiğini söyler. Ölçüler bir gösterge paneli değil, üç sayıdır. Geçmiş ise aşamaların neden böyle olduğunu açıklar: 5.2 aşamasının tarihi iki dizüstü bilgisayar geç geldiği için vardır; 7. gün görüşmesi, 30. gün değerlendirmesinin ilk haftada yanıtlanması gereken soruları bulmaya devam etmesi yüzünden vardır.

Biraz daha kısa ikinci bir örnek, distribütörleri olan bir ihracatçı için satış sürecinin şekli:

PR-SA-01 — Siparişten teslimata · Sahip: İhracat müdürü · Başlar: bir distribütörün siparişi geldiğinde · Biter: teslimat onaylanıp fatura gönderildiğinde
1. Sipariş kontrolü — hesap sahibi — girdi: sipariş — çıktı: sistemde onaylanan sipariş ya da distribütöre geri bir soru — kime: finans — en geç: bir iş günü
2. Kredi kontrolü — finans — girdi: onaylanan sipariş — çıktı: serbest bırakıldı ya da gerekçesiyle bekletildi — kime: depo — en geç: bir iş günü
3. Toplama ve paketleme — depo — girdi: serbest bırakılan sipariş — çıktı: çeki listesiyle paketlenmiş — kime: lojistik — en geç: üç iş günü
4. Belgeler ve sevkiyat — lojistik — girdi: paketlenmiş sipariş — çıktı: rezerve edilen sevkiyat, varış yerinin belgeleri eklenmiş, sistemde takip — kime: finans ve hesap sahibi — en geç: bir iş günü
5. Fatura ve onay — finans, ardından hesap sahibi — girdi: sevkiyat — çıktı: fatura gönderildi; teslimat distribütörle onaylandı ve kaydedildi — Kredi bekletilirse: hesap sahibi bir iş günü içinde distribütörü arar; serbest bırakma ya da ön ödeme kararını ihracat müdürü verir.

On iki satır; distribütördeki yeni bir çalışan da depodaki yeni bir kişi de kimi beklediğini biliyor.

Süreç belgesi ve üzerinden geçme oturumu, zaten kullandığınız araçlarda nerede durur

Belgenin kendisi ekibin belgelerinin durduğu yerde durur: paylaşılan bir kütüphanedeki bir Word dosyası, bir Google Doc, bir wiki sayfası, bir kanaldaki canvas. Üzerinden geçme bir toplantıdır ve her platformun, üzerinden geçmenin geride bıraktığı şey için bir yeri vardır; her biri farklı bir noktada durur. Yalnızca belgelenmiş davranış, satıcıların kendi sayfalarından, her sayfanın kontrol edildiği ayla birlikte:

PlatformSüreç üzerinden geçme, görüşme sırasında nerede not edilirGörüşmeden sonra üzerinden geçmeden ne geri gelir
Microsoft TeamsToplantı kontrollerindeki Notes: herhangi bir katılımcının ya da organizatörün düzenleyebildiği bir Loop bileşeni, kişileri etiketleyerek atanan görevlerle; ya da planlama sırasında toplantının Details bölümündeki Add an agendaOtomatik kaydedilir, Teams takviminden ve toplantı özetinden ulaşılır; notlardaki şey, bir kişinin yazdığı şeydir; dış katılımcılar bunlara erişemez ve düzenleyemez (Ekim 2026'da kontrol edildi)
Zoom WorkplaceAI Companion ile Meeting summary toplantıdan üretilir, üç bölümde (hızlı özet, özet, sonraki adımlar), ücretli Zoom Workplace planlarında; bir kişinin kendi notları ayrı bir belgedirÖzet e-postayla gönderilir, web portalındaki Summaries sayfasında listelenir ve Team Chat'te toplantının grup sohbetine gönderilebilir; katılımcılar özeti ev sahibi paylaşmayı seçtiyse alır, yalnızca ev sahibi düzenleyebilir ve kimliği doğrulanmamış kullanıcılar e-postayı almaz (Ağustos 2026'da kontrol edildi)
Google WorkspaceCalendar etkinliğinin açıklaması ya da ondan bağlanan bir Google Doc; uygun Workspace sürümlerinde ve Google AI planlarında, etkinlik oluşturulurken Calendar'da Take notes for me açılabilirNotlar toplantıdan sonra, ayara göre tüm konuklarla, kuruluş konuklarıyla ya da yalnızca ev sahipleriyle paylaşılan bir Google Doc olarak gelir; özellik aynı anda tek dili destekler, aynı toplantıda birden fazla dil konuşulması desteklenmez (Ekim 2026'da kontrol edildi)
SlackBir şablondan alınan, kanalda paylaşılan, hedefler, sonraki adımlar ve son tarihli action items bölümleri olan bir canvasCanvas kanalda bir belge olarak kalır; görüşmede söylenenler, biri yazmadıkça içinde yoktur (Ekim 2026'da kontrol edildi)

Her yerde iki şey aynıdır. Süreç belgesi yazıldığı tek dildeki bir dosyadır; başka bir dil okuyan meslektaş ya o dosyayı ya da birinin yaptığı bir kopyayı okur. Üzerinden geçmenin değiştirdiği şey ise belgeye ancak sonradan bir kişi aynı dilde yazarsa ulaşır. Bu paketlerin belgelediği çeviri belgeye değil görüşmeye aittir: Microsoft, organizatörün Teams Premium ya da Microsoft 365 Copilot lisansı olduğunda Teams toplantılarında canlı çevrilmiş altyazıları belgeliyor; Google ise uygun Workspace planlarında Meet'te çevrilmiş altyazıları belgeliyor (ikisi de Ağustos 2026'da kontrol edildi). Her birinin neyi kapsadığı ve nerede durduğu Microsoft Teams live translation ve Google Meet live translation yazılarında anlatılıyor. Yeni çalışanın salı günü açtığı süreç ve onu değiştiren üzerinden geçme oturumu bu altyazılardan ayrı nesnelerdir ve yazıldıkları dilde okunurlar.

Süreç, üzerinden geçme oturumu ve geçmişi her üye için nasıl okunabilir kalır

InterMIND, bir ekibin işinin bir kanalda yaşadığı bir iletişim alanıdır; bu yüzden bitmiş süreç belgesinin belli bir yuvası vardır: süreci yürüten ekibin kanalı. Yani her biri bir aşamanın sahibi olan İK, BT, finans ve işe alım yöneticilerinin ortak tek kanalı. Başlıkları ve numaralı listeleri olan, sonradan kendi menüsünden düzenlenen zengin metinli bir mesaj olan not olarak paylaşıldığında, her üye onu kendi dilinde okur; orijinal tek bir geçişle ulaşılabilir durumdadır. Not sabitlenir, böylece yeni bir meslektaşın ilk bulacağı şey güncel sürüm olur. Düzenleme geçmişi açıkken, değişen bir aşamanın önceki ifadesi, zaman damgasıyla birlikte kelime düzeyinde bir fark olarak güncel metnin üstünde görünür. Bir dosya olarak (PDF ya da Word belgesi) yüklendiğinde, her planda okuyucunun dilinde, her maddesi geldiği paragrafa bağlı bir yapay zekâ özeti taşır; böylece tek sayfalık okuma, kimse yazmadan önce vardır. Ücretli planlarda dosyanın kendisi okuyucunun diline çevrilmiş olarak açılır (belgeler için 30 dil). Ana kopya bir belge aracında kalıyorsa, güncellemeleri kanala e-postayla düşer: kanalın ev sahibi ona kendi adresini verir ve oraya gönderilen mesaj, gönderen adı ve ekler korunarak normal bir mesaj olarak görünür.

Üzerinden geçme o kanaldan başlar. Görüşme sırasında güncel sürüm, Share to conference ile video kutucuklarının yanında herkesin ekranına gelir: bir not ya da sohbette bağlantısı verilen bir Google Docs veya OneDrive belgesi. Her katılımcı onu bağımsız olarak kaydırır ve kendi dilinde okur; paylaşılan bir notu paylaşan kişi canlı düzenler, oda ise değişen devrin şekillenişini izler. Görüşme bittiğinde özet toplantının kendisinden yazılır: bir özet, kabul edildi, açık ya da tartışmalı diye işaretlenen noktalar, sahipleriyle aksiyon maddeleri; her satır zaman damgasını korur. Oturum sırasında paylaşılan belgelerin özetleri de söylenenlerin yanında katkıda bulunur. Özet e-postayla, kanalda bir mesaj olarak ve takvim etkinliğinde bir bağlantı olarak gelir ve oturum açmış her üye onu kendi dilinde okur: kayıt okuyucu başına çevrilir, odanın tesadüfen kullandığı dilde bir kez yazılmaz. Her üye onu düzenleyebilir, her düzenleme yazarını ve revizyon geçmişini korur ve kanal geçmiş her oturumun özetini saklar; böylece v1.3'ü üreten üzerinden geçme oturumu, v1.3 olan nottan bir tık uzaktadır. Bir üyenin kendi asistanı (Claude, ChatGPT, Copilot ya da Gemini; MCP bağlayıcısı üzerinden bağlı) özetlerde, transkriptlerde, sohbetlerde ve paylaşılan dosyaların metninde tek bir soruyla arama yapar, "dizüstü bilgisayar neden başlangıçtan beş gün önce gönderiliyor?" gibi, ve belgenin kendisini okur; bu, yapay zekâ özellikleri açık olan kuruluşlarda çalışır. Yukarıdaki tabloyla yan yana konduğunda fark, düz bir olgu beyanıdır: o paketlerin belgelediği altyazılar görüşme sürerken onu çevirir; burada ise süreç, üzerinden geçme oturumu ve geçmişi tek bir kayıttır ve her üye onu kendi dilinde okur.

Bir sürece katılan herkes çalışan olmayabilir. Bir distribütörün sipariş görevlisi, başka bir ülkedeki bir bordro sağlayıcısı, bir aşamanın sahibi olan bir yüklenici: kanalın dış üyesi e-postayla ücretsiz bir hesaba katılır ve süreci ve geçmişini herkes gibi okur. Hesabı olmayan kişi ise tek bir toplantının misafiridir: üzerinden geçme oturumuna bağlantıyla, bir telefondan, ücretsiz katılır, onu canlı olarak kendi dilinde dinler ve sonrasında kayıt almaz. Ev sahibi alanı sağlar ve ücretli bir planda yalnızca son 28 günde aktif olan üyeler için ödeme yapar: bir toplantıya katılan, bir sohbette yazan ya da asistana soru soran üyeler. Sessizleşen üyeler erişimlerini ücretsiz korur.

Zanaat olarak süreç dokümantasyonu her aracın ötesinde ayakta kalır: birinin yine üç gerçek vakayı izlemesi, aşamaları ikinci bir kişinin kontrol edebileceği devirler olarak yazması ve her rolden bir kişiyle tümünü baştan sona gözden geçirmesi gerekir. Ayakta kalması gerekmeyen şey ikinci iştir: her sürümün çevrilmiş bir kopyasını elle tutmak ve üzerinden geçmenin değiştirdiği şeyi, başkalarını okuyan insanlar için tek dilde yeniden yazmak.

SSS

Süreç dokümantasyonu nedir?

Süreç dokümantasyonu, bir işin kuruluşta onu başlatan olaydan bitiren sonuca kadar nasıl aktığının yazılı tarifidir: sırayla aşamalar, her birinin sahibi olan rol, bir rolden diğerine ne geçtiği, her aşamanın geride ne bıraktığı, normal yolun dışındaki istisnalar ve bunlara kimin karar verdiği, ve sahibin izlediği birkaç sayı. Süreç haritası olan diyagram ile her aşamanın adım adım nasıl yapıldığını anlatan SOP'ler arasında yer alır.

Süreç dokümantasyonuna neler eklenmeli?

Kimlik, sürüm, sahip, yürürlük tarihi ve bir sonraki gözden geçirme tarihini içeren bir başlık bölümü; amaç ve sonuç; tetikleyici ve bitiş durumu; sürecin neyi kapsamadığı dahil kapsam; adı belli tek bir süreç sahibiyle roller; sırayla aşamalar, her birinde rol, girdi, çıktı ve nerede kaydedildiği, sonraki rol ve süre sınırı; her biri için bir karar vericisiyle istisnalar ve yükseltme; iki ya da üç ölçü; ve ilgili SOP'ler, sürecin uyguladığı politika ve bir revizyon geçmişi.

Bir süreç adım adım nasıl belgelenir?

Net bir tetikleyicisi ve bitiş durumu olan tek bir süreç seçin. Üç gerçek vakayı baştan sona izleyin ve dallar dahil gerçekte olanı yazın. Önce aşamaları, şablonda, her birini bir devir olarak (rol, girdi, çıktı, sonraki rol, süre sınırı) taslak olarak yazın. Vakaların ortaya çıkardığı istisnaları, her birine kimin karar verdiğiyle ekleyin. Amacı, kapsamı, rolleri ve başlık bölümünü doldurun. Belgeyi her rolden bir kişiyle gözden geçirin; her biri kendi aşamasını yüksek sesle okusun ve devirleri onaylasın. Ekibin zaten okuduğu yerde, sahibi ve gözden geçirme tarihi görünür şekilde yayımlayın ve gözden geçirme tarihini takvime koyun.

Süreç dokümantasyonu ile SOP arasındaki fark nedir?

Süreç dokümantasyonu, işin roller ve ekipler arasında nasıl aktığını (aşamalar, devirler, her aşamanın geride bıraktığı) süreç başına bir sayfa düzeyinde anlatır. SOP ise bu aşamalardan birinin bir rol tarafından, her adımın ürettiği sonuca kadar, adım adım nasıl yapıldığını anlatır. Süreç belgesi SOP'lerin nerede gerektiğini ve kimin neyi kime devrettiğini söyler; bir SOP ise bir kişiye salı sabahı ne yapacağını söyler. Ekipler arası bir sürecin tamamı için SOP yazmak kimsenin açmadığı bir kılavuz üretir; süreç belgesini SOP ayrıntısında yazmak da aynı şeyi üretir.

Süreç dokümantasyonu örnekleri nelerdir?

Net bir başlangıcı ve bitişi olan, roller arasında geçen her yinelenen akış: yeni bir çalışanın imzalı sözleşmeden 30. güne kadar oryantasyonu; bir distribütörden gelen siparişin onaylı teslimata ve faturaya kadar akışı; bir müşteri şikâyetinin alımdan kapanışa kadar akışı; bir hastanın sevkten ilk randevuya kadar akışı; yeni bir ürünün onaylı brifingden kataloğa girmesine kadar akışı; puantajlardan gönderilmiş faturalara kadar ay sonu kapanışı. Bu rehberdeki çalışılmış örnek çalışan oryantasyonudur: dört rolde altı aşama, üç istisna, üç sürümlük bir geçmiş. Ardından daha kısa bir siparişten teslimata örneği gelir.

Word ya da Google Docs'ta bir süreç dokümantasyonu şablonu var mı?

Bu rehberdeki şablon kalın etiketli düz metindir; bu yüzden yeniden biçimlendirmeye gerek kalmadan bir Word belgesine, bir Google Doc'a, bir wiki sayfasına, bir Slack canvas'ına ya da bir sohbet notuna yapıştırılabilir. Dosyadan çok format önemlidir: belgeyi tutan şey sahibi ve gözden geçirme tarihiyle başlık bölümünü, tetikleyiciyi ve bitiş durumunu, süre sınırıyla roller arası devirler olarak yazılmış aşamaları, her istisna için adı belli bir karar vericiyi ve bir revizyon geçmişini barındırmalı. Ayrıca sürecin yürütücülerinin zaten okuduğu yerde durmalı.

Süreç dokümantasyonunu kim yazmalı?

Süreç sahibi: akışın tamamından sorumlu, adı belli tek kişi, genellikle sürecin çoğunlukla içinden geçtiği alanın yöneticisi; yanında bir aşamayı üstlenen her rolden bir kişiyle. Kalemi ve gözden geçirme tarihini sahip tutar; aşamaları yapanlar eş yazarlardır, çünkü onlarla birlikte değil onlar hakkında yazılan belge süreci tasarlandığı gibi anlatırken gerçeği onların kafasında yaşar. Yeni gelen kişi test edicidir: kendi aşamasını ve yanındaki iki aşamayı bir dakikadan kısa sürede bulabiliyorsa belge işliyordur.

Süreç dokümantasyonu ne sıklıkla güncellenmeli?

Başlığındaki gözden geçirme tarihinde: altı ya da on iki ayda bir olağandır, süreç düzenlemeye tabiyse daha kısa; ve dört şeyden biri olduğunda daha erken: bir devir başarısız oldu ve kimse sahiplenmedi, bir aşamanın dayandığı bir araç ya da form değişti, sürecin uyguladığı kural değişti ya da ölçüler kaydı. Her güncelleme, geçmişte neyin değiştiğini ve kimin onayladığını söyleyen tek satırla yeni bir sürümdür; eski sürüm saklanır ve aşaması değişen kişilere değişen satırlarla aynı gün haber verilir.


Kaynaklar: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Use live captions in Microsoft Teams meetings; Zoom — Using Meeting Summary with AI Companion; Google — Calendar & Meet settings for "Take notes for me"; Google Meet — "Take notes for me" in Google Meet; Google Meet — Use translated captions; Slack — Meeting agenda template (canvas). Microsoft, Google ve Slack toplantı notları ile şablon sayfaları Ekim 2026'da; Zoom toplantı özeti sayfası ile Teams ve Meet altyazı sayfaları Ağustos 2026'da kontrol edildi. Satıcılar planları, özellikleri ve dil listelerini zaman içinde değiştirir; güncel durum için sayfalarına bakın.

Toplantılar ve özetler kategorisinde daha fazlası

Toplantılar ve özetler kategorisindeki tüm yazılar
SOP nasıl yazılır: adımlar, şablon, örnek, gözden geçirme döngüsü — ve SOP yazıldıktan sonra nerede durur (2026)
Toplantılar ve özetler

SOP nasıl yazılır: adımlar, şablon, örnek, gözden geçirme döngüsü — ve SOP yazıldıktan sonra nerede durur (2026)

Bir SOP yazmak için tekrarlanan tek bir işi seçin, o işi yapan kişiyi izleyin, önce numaralı adımları taslak haline getirin — her biri bir rol ve bir fiille başlasın, başkasının kontrol edebileceği bir sonuçla bitsin — istisnaları ve kayıtları ekleyin, bir kimlik numarası, bir sahip ve bir gözden geçirme tarihi verin, işe yeni başlayan biriyle test edin, ardından ekibin zaten okuduğu yerde yayımlayın. Sırasıyla yedi adım, kopyalayabileceğiniz tek sayfalık bir şablon, uygulamalı bir örnek, prosedürü güncel tutan gözden geçirme döngüsü, SOP yazıldıktan sonra Teams, Zoom, Google Workspace ve Slack içinde nerede durduğu — ve prosedürün ile her gözden geçirmesinin her üye için kendi dilinde nasıl okunabilir kaldığı.

The Mind.com Team

Görev nasıl devredilir: kalıcı olan devir teslim — brief, sorumlu, son tarih ve her iki tarafın da okuyabileceği bir kayıt (2026)
Toplantılar ve özetler

Görev nasıl devredilir: kalıcı olan devir teslim — brief, sorumlu, son tarih ve her iki tarafın da okuyabileceği bir kayıt (2026)

Bir görevi devretmek için adım listesi yerine bir sonuç teslim edin: sonucu, son tarihi ve sınırları içeren tek paragraflık bir brief, açıkça "evet" diyen tek bir sorumlu, iş başlamadan önce kararlaştırılan bir kontrol görüşmesi ve her iki tarafın daha sonra okuyabileceği bir yerde tutulan bir devir teslim kaydı. Adım adım yöntem, kopyalayabileceğiniz bir brief şablonu, birden fazla kişinin dahil olduğu işler için bir RACI tablosu, nelerin devredilip nelerin elde tutulacağı, devir teslimin Teams, Zoom, Google Workspace ve Slack içinde nerede durduğu ve görevin bir sonraki özette yapıldı ya da yapılmadı olarak, her üyenin kendi dilinde nasıl geri geldiği.

The Mind.com Team

Uzaktan çalışma politikası: şablon, bölümler, örnek — ve politikanın yaşadığı tek kanal (2026)
Toplantılar ve özetler

Uzaktan çalışma politikası: şablon, bölümler, örnek — ve politikanın yaşadığı tek kanal (2026)

Uzaktan çalışma politikası, ofis dışında çalışmaya ilişkin yazılı kurallar bütünüdür: kimin, nereden çalışabileceği, ne zaman ulaşılabilir olması gerektiği, ekibin nasıl iletişim kurduğu, ekipman ve bağlantı masraflarını kimin karşıladığı, şirket verilerinin nasıl güvende tutulduğu ve politikanın kendisinin nasıl gözden geçirildiği. Kullanışlı bir politikanın içermesi gereken on bölüm, kopyalayabileceğiniz bir şablon, üç ülkede kırk kişilik bir şirket için doldurulmuş bir örnek, politikanın ve gözden geçirmesinin Teams, Zoom, Google Workspace ve Slack içinde nerede yer aldığı — ve tek bir kanalın politikayı, politikayla ilgili her soruyu ve her değişikliği her üyenin kendi dilinde okunabilir kılması.

The Mind.com Team

Yeni gönderileri ve ürün güncellemelerini e-posta ile al

Ayda bir, yeni gönderiler ve ürün güncellemeleri içeren e-posta. İstediğiniz zaman abonelikten çıkın.