Yayınevi yönetim sistemi nedir? Hangi modülleri içermeli?

“Yayınevi yönetim sistemi” diye arattığınızda garip bir boşlukla karşılaşırsınız: karşınıza ya genel muhasebe programları çıkar, ya dergi makale-takip yazılımları, ya da kitapçılar için stok programları. Her biri yayınevinin bir organını yönetir; hiçbiri yayınevini yönetmez.

Bu boşluk tesadüf değil. Yayıncılık yazılım pazarı tarihsel olarak dikey büyüdü: dergiler için ayrı sistemler (dünyada OJS 58 bine yakın dergiyle bu kategorinin devi), hastane-tipi makale takip araçları, matbaa yazılımları, kitap satışı için genel e-ticaret paketleri… Yayınevi ise dikey değil yataydır: aynı kurum aynı hafta içinde hakem raporu bekler, matbaa teklifi onaylar, kargo yetiştirir ve telif hakedişi hesaplar.

Bu yazı, “yayınevi yönetim sistemi” kategorisini tanımlama denemesi: böyle bir sistemden ne beklemelisiniz, neyi eksik bulursanız aslında elinizde başka kategoriden bir araç var demektir?

Tanım: eserin tüm hayatını taşıyan sistem

Yayınevi yönetim sistemi, bir eserin başvurudan satış sonrasına kadar tüm yaşam döngüsünü tek veri modeli üzerinde yöneten yazılımdır. Kritik ifade “tek veri modeli”: dergi yazılımı + muhasebe programı + e-ticaret paketini yan yana koymak bir sistem değil, bir koleksiyondur. Sistem olmanın ölçütü, satış gerçekleştiğinde faturanın, stok düşümünün ve telif tahakkukunun aynı olayın sonuçları olarak kendiliğinden işlenmesidir — üç programa üç ayrı giriş olarak değil.

Olmazsa olmaz modüller

Kategorinin çekirdeğini yedi başlıkta özetleyebiliriz:

1. Başvuru ve değerlendirme. Eser tipine göre başvuru formları, ön inceleme, hakem yönetimi, karar süreçleri. Dergi-odaklı sistemlerin güçlü olduğu alan; kitap ve bölüm süreçlerini de aynı disiplinle taşıması gerekir.
2. Üretim operasyonları. Redaksiyon, çeviri, dizgi, kapak, matbaa koordinasyonu; görev atama ve kalite kontrolleri. Çoğu araçta tümüyle eksiktir — üretim, e-postada yaşar.
3. Katalog, edisyon ve stok. ISBN/ISSN yönetimi, basım ve tiraj kayıtları, format bazlı edisyonlar, denetimli stok hareketleri. Kitap tarafında bu modülün anatomisini kitap yönetim sistemi yazısında, eser–edisyon–format ilişkisini ise baskı, edisyon ve ISBN yazısında açtık.
4. Satış vitrini. Kurumun kendi alan adında, katalogla canlı bağlı bir mağaza: basılı, dijital, paket; misafir sipariş; dijital kütüphane. Ayrı bir e-ticaret paketine elle katalog taşımak, kopukluğun başladığı yerdir. Kitap tarafında yaygın açık kaynak araçların satış yeteneğinin zayıflığı (ör. OMP’de ödemenin eklenti düzeyinde kalması) bu ihtiyacı yıllardır açıkta bırakıyor.
5. Muhasebe ve telif. Faturalama, çift kayıtlı defter entegrasyonu, telif sözleşmeleri ve dönemsel hakediş. “Excel’e dökeriz” cümlesi, bu modülün yokluğunun itirafıdır.
6. Belge üretimi. Kabul mektubu, sözleşme, makbuz gibi belgelerin kurum şablonundan otomatik ve doğrulanabilir üretimi.
7. Raporlama ve denetim. Editoryal ve mali panolar; kim-ne zaman-ne yaptı sorusuna cevap veren değiştirilemez denetim kaydı.

Seçim kriterleri: modül listesinin ötesi

İki sistem aynı modül listesini sunabilir ve bambaşka yaşanabilir. Modül listesinden sonra sorulacak sorular:

• Süreçler koda mı, ayara mı yazılı? Kurumunuzun değerlendirme adımları değiştiğinde tedarikçiden geliştirme mi bekleyeceksiniz, panelden mi düzenleyeceksiniz?
• Veri kimin elinde, nerede? Verileriniz size mi ait, ortak bir havuzda mı? Talep hâlinde kendi sunucunuzda tutulabiliyor mu?
• Roller gerçekten ayrık mı? Muhasebecinin hakem raporu görememesi bir görüş meselesi değil, tasarım sorusudur.
• KVKK yerli mi, yamalı mı? Açık rıza kayıtları, veri saklama, loglarda kişisel veri — sonradan eklenen uyum, hep eksik kalır.
• Kurulum ve yaşatma yükü kimde? Uluslararası deneyim, açık kaynak araçlarda bile kurulum ve bakımın teknik uzmanlık istediğini gösteriyor; kurumda o kapasite yoksa yükü üstlenecek bir muhatap olmalı.

Bu kriter setiyle mevcut araçlarınızı puanlamak yarım saatlik bir çalışmadır ve genellikle şu sonucu verir: her aracınız kendi dikeyinde iyidir; kopukluk aralarındadır.

“Hepsi bir arada” ile “hepsi entegre” aynı şey değil

Kategori tanımında sık düşülen bir tuzağı ayrıca işaretleyelim. Bazı tedarikçiler, ayrı ürünlerini yan yana koyup “uçtan uca çözüm” olarak sunar: bir dergi sistemi + bir e-ticaret paketi + bir muhasebe yazılımı, aralarında veri aktarım köprüleriyle. Broşürde tek çözümdür; sahada üç ayrı sistemdir.

Farkı test etmenin pratik yolu, sınır senaryoları sormaktır:

• Müşteri bir kitabı iade etti; telif tahakkuku kendiliğinden düzeliyor mu, yoksa muhasebede elle mi düzeltilecek?
• Bir eserin adı değişti; mağaza sayfası, sözleşme kayıtları ve faturalardaki görünüm tek yerden mi güncelleniyor?
• Yazar panelden geçmiş başvurusuna bakarken, aynı eserin mağazadaki satış durumunu kurum aynı kayıtta görebiliyor mu?
• Denetim gerektiğinde “bu eserle ilgili her işlem” tek zaman çizelgesinde mi, üç sistemin loglarında mı?

Köprülü mimaride bu soruların cevabı hep “aktarım çalışırsa”dır — ve aktarımlar, en yoğun gününüzde bozulma alışkanlığıyla ünlüdür. Tek çatı altında ise sorular anlamsızlaşır; çünkü düzeltilecek ikinci bir kopya yoktur.

Bu ayrım satın alma sürecinde nadiren görünür, kullanımın altıncı ayında ise her şey olur. Demoda “modül listesi” yerine yukarıdaki dört senaryoyu sorun; cevap veriş biçimi, mimariyi broşürden daha iyi anlatır.

Kategoriyi biz de bu boşluk için kurduk

Açıkça söyleyelim: Nasirus’u tam bu tanıma oturması için geliştirdik — dört eser tipi, tek sistem; değerlendirmeden e-ticarete, muhasebeden denetim kaydına yukarıdaki başlıkların tamamı aynı çatı altında. Yukarıdaki kriterler de bizim masamızdaki pusula: süreçler kurumun elinde, veriniz size ait, yetkiler katmanlı, KVKK baştan.

Kendi araç envanterinizi bu yazıdaki çerçeveye koyup değerlendirmek isterseniz, modül dökümüne bakın ya da envanterinizi bize yazın — hangi parçanın sistemde, hangisinin yerinde kalmasının mantıklı olduğunu birlikte çıkaralım.