İçeriğe atla
This page is also available in English.View in English
Diese Seite gibt es auch auf Deutsch.Auf Deutsch ansehen
Süreç5 Mayıs 2026 · 4 dk okuma

Yayınevinde roller ve yetkiler: herkes her şeyi görmeli mi?

Muhasebeci hakem raporunu, e-ticaret operatörü yazar yazışmalarını görmeli mi? Yayınevi yazılımında rol ve yetki tasarımının incelikleri.

Küçük yayınevlerinde yetki diye bir sorun yokmuş gibi görünür: üç kişi her işi birlikte yapar, herkes her şeyi bilir. Sorun, dördüncü kişiyle başlar. Muhasebeye biri gelir, e-ticareti bir öğrenci asistan devralır, dışarıdan bir dizgici çalışılır — ve bir gün fark edilir ki telif sözleşmelerinin durduğu klasöre herkesin erişimi vardır.

Yetki tasarımı, güvensizlik değil özen meselesidir. Bu yazıda bir yayınevinin rollerini nasıl düşünmesi gerektiğini ve “herkes yalnız kendi işini görsün” ilkesinin pratikte neye benzediğini anlatacağız.

Rol dediğimiz şey aslında bir izin paketi

“Editör”, “sekreterya”, “muhasebeci” gibi adlar günlük dilde unvandır; yazılımda ise birer izin paketidir. Sekreterya başvuruların tamlığını kontrol edebilir ama kabul kararı veremez. Yayın editörü hakem atayabilir ama dönem kapanışı yapamaz. Matbaacı yalnızca kendi baskı işlerini görür.

Bu paket yaklaşımının iki pratik sonucu vardır. Birincisi, bir kişi birden fazla rol taşıyabilir — küçük kurumlarda aynı kişi hem editör hem üretim sorumlusudur ve bu tamamen normaldir. İkincisi, yetki kişiye değil role bağlanır: editör değiştiğinde yapılacak iş, yeni kişiye rolü vermekten ibarettir; kimse “eski editörün erişimleri tek tek kapatıldı mı” diye gece uykusu kaçırmaz.

Ekran yetkisi yetmez: üç katman

Yetkiyi yalnızca “kim hangi sayfayı görür” düzeyinde kurmak, en sık yapılan eksikliktir. Sağlam bir model üç katmanda çalışır:

  1. Ekran düzeyi: Muhasebe paneline muhasebeci girer. Basit ve gerekli — ama tek başına yetersiz.
  2. Akış düzeyi: Bir eser hangi aşamadaysa, o aşamanın aksiyonlarını yalnızca o aşamanın sorumlusu görür. “Kabul et” düğmesi, süreç hakem aşamasındayken editörün ekranında yoktur; çünkü o an editörün işi değildir.
  3. İlişki düzeyi: Aynı role sahip iki kişiden yalnızca eserle ilişkili olan onu görür. Bir hakem, atandığı eserin dosyasını görür; havuzdaki diğer yüz eserin değil. Yazar, kendi taslağını görür; taslak durumundaki bir eser, sahibi dışında kimsenin karşısına çıkmaz.

Üçüncü katman en az konuşulanı ama en kritik olanıdır; çift-kör hakemliğin gündelik hayatta korunduğu yer orasıdır.

Beş yüzey: aynı sistem, ayrı kapılar

Nasirus bu düşünceyi mimariye taşır: tek sistem, beş ayrı yüzeyden kullanılır. Okuyucu mağazayı görür; yazar, hakem ve editörler uygulama panelini; yayınevi operasyonu yönetim panelini; muhasebeci kendi panelini; e-ticaret operatörü ticaret panelini.

Bu ayrımın güzelliği, “yanlışlıkla” kategorisini ortadan kaldırmasıdır. E-ticaret operatörü yayın süreçlerine, hakem üretim yazışmalarına yanlışlıkla bile giremez — çünkü o kapı onun yüzeyinde yoktur. Mağazadan üye olan bir okuyucunun hesabı da panel tarafına yetki taşımaz; okuyucu dünyası ile kurum dünyası ayrı yaşar.

Küçük kurum itirazı: “Biz üç kişiyiz, bize fazla değil mi?”

Rol tasarımı anlatılınca küçük yayınevlerinden hep aynı itiraz gelir: “Bunlar büyük kurum işleri; bizde herkes her işi yapıyor zaten.”

İki cevap var. Birincisi pratik: rol modeli, küçük kurumda da çalışır — sadece aynı kişiye birden çok rol verilir. Üç kişilik bir yayınevinde bir kişi editör + üretim sorumlusu, diğeri sekreterya + e-ticaret operatörü olabilir. Sistemin gördüğü roller nettir; kişilerin şapka değiştirmesi serbesttir. Kurum büyüdüğünde yapılacak tek şey, şapkaları ayrıştırmaktır — sistemi yeniden kurmak değil.

İkincisi daha az konuşulanı: küçük kurumda bazı ayrımlar büyük kurumdakinden bile kritiktir. Üç kişilik ekipte “muhasebe kayıtlarına kim dokundu” sorusunun cevabı zaten bellidir; ama dışarıdan çalışılan dizgici, çevirmen ve matbaacı da sisteme girmeye başladığında — ki verimin asıl sıçradığı nokta orasıdır — iç-dış ayrımı hayati olur. Dış paydaşın yalnızca kendi görevini görmesi, küçük yayınevinin sözleşme ve yazar verisini koruyan asgari çittir.

Kısacası rol modeli bir “kurumsal lüks” değil; ekip üç kişiyken kurulursa on kişiye zahmetsiz büyüyen, on kişiyken kurulmaya çalışılırsa sancılı olan bir temeldir.

“Ya acil bir durumda?” — istisnanın da kaydı olur

Yetki tasarımına itirazın klasiği şudur: “Kural katı olursa acil durumda iş durur.” Haklı bir endişe; cevabı kuralları gevşetmek değil, istisnayı kayıtlı kılmaktır.

Yanlış işlenmiş bir adımın yetkili tarafından geri alınabilmesi buna iyi bir örnek: geri alma vardır, ama kayıtsız değildir. Acil durumda kapı açılır; kimin, ne zaman, hangi gerekçeyle geçtiği de bilinir. İstisna serbesttir; izsiz istisna yoktur.

Kendi kurumunuz için başlangıç sorusu

Rol şemanızı gözden geçirmek istiyorsanız tek soruyla başlayın: “Bu kişi işini yapmak için bu bilgiyi görmek zorunda mı?” Cevap hayırsa, görmemeli — kişiye güvensizlikten değil, yazar verisinin, hakem kimliğinin ve mali kayıtların taşıdığı sorumluluktan.

Bu soruyu kurumunuzdaki her rol için sorduğunuzda elinize çıkan tablo, iyi bir yazılımda “özel geliştirme” değil, kuruluş günü yapılan bir yapılandırmadır. Kendi rol tablonuzu birlikte kurmak isterseniz demo talep edin — demoya muhasebecinizi ve e-ticaret sorumlunuzu da getirin; en doğru sorular onlardan gelir.

Diğer yazılar

RehberAkademik dergi nasıl kurulur? ISSN'den ilk sayıya, TR Dizin'e uzanan yolRehberBaskı, edisyon ve ISBN: 2. baskıda ISBN değişir mi?RehberDergi yönetim sistemi nedir? DergiPark, OJS ve ticari sistemler arasında seçim