Evrak Takip Programı: Belge Akışını Otomatikleştirme Rehberi

Bir müşteri sözleşmesinin son hâli muhasebecinin masaüstünde, imzalı tarama hâli satışçının Gelen Kutusu’nda, taslak hâli ortak sürücüde sozlesme_son_SON_v3.docx adıyla duruyor. Yenileme tarihi geçtiğinde kimse fark etmiyor; fark ettiğinde de üç kopyadan hangisinin yürürlükte olduğu tartışılıyor.

Bu tablo bir disiplin sorunu değil, kayıt yerinin belirsiz olmasının doğal sonucu. Belgenin doğduğu anda gideceği yer belli değilse, herkes kendi en hızlı yolunu seçer — ve o yol her zaman kişiseldir.

---

Belge kaybının dört ayrı sebebi vardır

Şirketler bu sorunu tek başlıkta (“arşiv düzensiz”) toplayıp tek çözüm arar. Oysa dört ayrı sebep vardır ve her biri farklı çözülür:

1. Kayıt yeri yok. Belge üretildiği anda gideceği kayıt kalemi tanımsız. Muhasebeci sözleşmeyi masaüstüne kaydeder, çünkü başka gidecek yer görmez.
2. Sürüm belirsiz. Aynı belgenin dört kopyası dolaşır, hangisinin imzalı olduğunu yalnız üretense bilir.
3. Bitiş tarihi kimsenin işi değil. Sertifikanın, sözleşmenin, periyodik muayenenin son günü hiçbir sistemde alan olarak yok; takvim bilgisi insanın hafızasında.
4. Yetki yok, bu yüzden paylaşım da yok. Personel özlük dosyasını herkesin göreceği ortak sürücüye koymamak için kişisel bilgisayarda tutmak, çoğu yerde bilinçli bir tercihtir.

Dördünü aynı anda çözmeyen bir “doküman yönetim sistemi”, klasör yapısının daha pahalı bir kopyası olur.

---

Belge sisteme nereden girer: doğduğu yerden

Evrak sisteminin başarısızlığa gittiğinin en net işareti, ayrı bir “belge yükleme ekranı” olmasıdır. Kimse günlük işini bitirdikten sonra ikinci bir ekrana girip dosya yüklemez.

Doğru kurulum, belgenin zaten kullanılan ekranın içinde doğmasıdır:

• Satışçı teklifi onayladığında sözleşme taslağı o iş kaydının altında oluşur.
• Depo görevlisi mal kabulü kapattığında irsaliye görseli o kabul kaydına bağlanır.
• Teknisyen bakımı bitirdiğinde ölçüm raporu o bakım kaydının eki olur.
• Muhasebe faturayı kestiğinde PDF cari hesabın altına düşer.

Elevatora SAHA’da bakım formu ve ölçüm raporu bu şekilde çalışıyor: teknisyen sahada işi kapatırken belge zaten iş kaydına bağlanmış oluyor, ayrıca kimsenin yüklemesi gerekmiyor. Elevatora İMALAT’ta üretim partisine ait kalite kaydı aynı mantıkla parti numarasının altında duruyor.

Kural: Belgeyi ayrıca yüklemesi gereken hiçbir sistem uzun ömürlü olmaz. Belge, işin bir yan ürünü olarak kayda girmelidir.

---

Sürüm takibi: “son_SON_v3” problemi

Sürüm takibi, aynı belgenin her değişikliğinin ayrı ayrı saklanması ve hangisinin yürürlükte olduğunun sistemce işaretlenmesidir. Pratikte üç alan yeterlidir:

Alan	Ne yapar	Yoksa ne olur
Sürüm numarası	Her yükleme yeni sürüm açar, eskisi silinmez	Değişikliğin ne zaman yapıldığı tartışılır
Yürürlük işareti	Tek bir sürüm “geçerli” olarak işaretlidir	Dört kopyadan hangisinin imzalı olduğu bilinmez
Değişikliği yapan + tarih	Kim, ne zaman değiştirdi	Sorumluluk kimsede kalmaz

Bu üçlü, denetim izinin (audit trail — kim ne zaman ne yaptı kaydı) belge tarafındaki karşılığıdır. Bir uyuşmazlıkta “hangi metni imzaladık” sorusunun cevabı buradan çıkar.

---

Bitiş tarihi olan belgeler: asıl kazanç burada

Şirketlerin evrak sisteminden aldığı en somut fayda arama değil, süresi dolan belgenin zamanında yakalanmasıdır. Bitiş tarihi olan belge sınıfları:

• Müşteri ve tedarikçi sözleşmeleri (yenileme / fesih ihbar süresi)
• Personel sertifikaları, yetki belgeleri, sağlık raporları
• Makine ve araç muayeneleri, kalibrasyon kayıtları
• Sigorta poliçeleri, kira sözleşmeleri, banka teminat mektupları
• İşletme ruhsatları, kalite belgeleri (ISO vb.)

Kurulum şu şekilde: her belge tipine bir bitiş tarihi alanı ve bir ön uyarı penceresi (ör. 60 gün) tanımlanır. Tarih yaklaştığında sistem sorumluya düşer; sorumlu tepki vermezse üst kademeye tırmanır. Bu, klasik bir onay akışı kurgusunun belge tarafındaki uygulamasıdır.

Fesih ihbar süresi kaçırılmış tek bir sözleşmenin bedeli, çoğu şirkette bu modülün maliyetini tek başına karşılar.

---

OCR ne yapar, nerede yetmez

OCR (optik karakter tanıma), taranmış bir belgenin görüntüsündeki yazıyı aranabilir metne çevirir. Faydası gerçektir: 4.000 sayfalık tarama arşivinde bir cari unvanını saniyeler içinde bulursunuz.

Yetmediği yer şurası:

• Alan çıkarmaz. “Bu sözleşmenin bitiş tarihi 31.12.2027” cümlesini metne çevirir, ama bu tarihi hatırlatma üretecek bir alana yazmaz — bunu yapan ayrı bir çıkarım katmanıdır.
• El yazısını ve kötü taramayı zorlanarak okur. Kaşe üstüne düşmüş imza, eğik çekilmiş telefon fotoğrafı, soluk faks çıktısı hata üretir.
• Türkçe karakterlerde hata payı yüksektir. “İ”, “ı”, “ş” karışması aramayı sessizce boşa düşürür; bu yüzden aramanın yalnız OCR metnine dayanması risklidir.
• Doğruluğu kimse onaylamaz. OCR’ın okuduğu tutarla belgedeki tutar farklıysa bunu yakalayan bir kontrol yoksa, sistem yanlış veriyi güvenle taşır.

Doğru kurulum: OCR aramayı besler, kritik alanları (tutar, tarih, taraf) ise kullanıcı tek ekranda onaylar. Bu ayrımın detayı veri girişi otomasyonu yazısında.

---

Arama ve yetki: iki ayrı tasarım kararı

Arama üç katmanda çalışmalıdır: kayıt alanları (cari, iş numarası, tarih aralığı), dosya adı, ve belge içi metin. Yalnız dosya adına dayanan arama, adlandırma disiplini olmayan hiçbir şirkette işe yaramaz.

Yetki ise belge tipine göre kurulur, kişiye göre değil:

Yetki matrisinde tipik kırılım

Özlük dosyaları yalnız İK ve ilgili kişinin kendisi. Sözleşmeler satış, hukuk ve yönetim. Mali belgeler muhasebe ve yönetim. Teknik raporlar operasyon ekibi ve o işin müşterisi. Her belge tipi için “kim görür, kim yükler, kim siler” ayrı ayrı yazılır — silme yetkisi çoğu şirkette hiç kimsede olmamalı, yerine arşivleme kullanılmalıdır.

Yetkiyi kişi bazında kurmak ilk gün kolaydır, altıncı ayda yönetilemez hâle gelir. Erişim kayıtlarının nasıl tutulduğu konusunda kurumsal yazılım güvenliği yazısındaki ilkeler geçerlidir.

---

Kapsam ve bant

Kapsam	Ne içerir	Bant	Süre
Tek süreç	Tek belge ailesi (ör. sözleşmeler): kayıt, sürüm, hatırlatma, arama	80.000 - 150.000 ₺	2-4 hafta
Kurumsal sistem	Çok belge tipi, yetki matrisi, mevcut ERP/CRM bağı, OCR arama	200.000 - 400.000 ₺	4-8 hafta
Ek modül	Yeni belge tipi, e-posta eki toplayıcı, KEP bağlantısı	8.000 - 45.000 ₺	—

Barındırma ilk yıl dahildir, sonrasında 4.800 veya 9.600 ₺/yıl. Yıllık bakım isteğe bağlıdır (%12, %18 veya %25). Lisans ömür boyu, kullanıcı sayısı sınırsız, kaynak kod teslim edilir. Ayrıntı için fiyat sayfası.

İlk tıklanabilir prototip 2-4 hafta içinde elinizde olur; kendi belge tiplerinizi görmeden karar vermeniz gerekmez.

---

İlgili Bütçe Araçları ve Karşılaştırma Rehberleri

• Paket vs Özel 5 Yıllık TCO Hesaplayıcı — Kiralık SaaS lisansı ile özel yazılımın 5 yıllık maliyetini kıyaslayın.
• Yazılım Bütçe ve Süre Tahmincisi — İhtiyacınız olan modülleri seçerek bütçe ve teslim bandınızı görün.
• ERP Fiyat Listesi 2026 Karşılaştırması — Türkiye kurumsal ERP lisans ve bakım bedelleri.
• Özel Yazılım Teknik Şartnamesi (RFP) Rehberi — Bütçe aşımını önleyen şartname hazırlama kılavuzu.

Sıkça sorulan sorular

OCR kurarsak belge sorunumuz çözülür mü?

Hayır, yalnız bir kısmı çözülür. OCR (optik karakter tanıma) taranmış bir görselin içindeki yazıyı aranabilir metne çevirir; yani PDF'in içinde geçen firma adını bulmanızı sağlar. Ama belgenin hangi işe ait olduğunu, kaçıncı sürüm olduğunu, ne zaman yenilenmesi gerektiğini ve kimin görebileceğini bilmez. Bu dört alan sistemde ayrı alan olarak tutulmazsa OCR yalnız daha hızlı bir arama kutusu olur.

Mevcut klasörlerdeki on binlerce eski belge ne olacak?

İki ayrı kova yapıyoruz. Bugünden sonra üretilen belgeler doğduğu ekranda sisteme girer. Eski yığın olduğu gibi arşive alınır, dosya adı ve klasör yolu üzerinden aranabilir hâle getirilir; yalnız hâlâ yürürlükte olan sözleşme ve sertifikalar tek tek etiketlenir. Tüm geçmişi elle etiketlemek çoğu şirkette gereksiz maliyettir.

E-posta eklerini sistem kendisi toplayabilir mi?

Evet. Belirlenen bir kutuya (ör. evrak@sirket.com) düşen e-postaların ekleri otomatik alınır, gönderen ve konu satırından ön sınıflandırma yapılır, sorumluya 'bu belge hangi işe ait?' diye tek soruluk bir onay ekranı düşer. Kaynağı belirsiz eki kimse etiketlemeden arşive atmak, kaybolmanın yerini değiştirmekten başka bir şey yapmaz.

Belgeleri KEP veya e-imza ile birlikte kullanabilir miyiz?

Evet. İmzalı PDF sistemin içinde ayrı bir sürüm olarak tutulur, imza tarihi ve imzalayan kişi kayıt alanına yazılır. Islak imzalı orijinali fiziki dosyada kalan belgelerde ise kaydın üstüne fiziki dolap ve klasör numarası yazılır; sistem hangi rafta olduğunu söyler.

Belgeye kim, hangi yetkiyle erişir?

Rol bazlı: sözleşmeyi finans ve satış, bordroyu insan kaynakları, sertifikayı kalite görür. Arama sonucu da yetkiye göre filtrelenir; kişi göremeyeceği belgenin varlığını da görmez. Yetki matrisi keşifte yazılır.

Kurulum ne kadar sürer, ne kadar tutar?

Belge kaydı, sürüm takibi, bitiş tarihi hatırlatması ve e-posta eki toplama tek süreç kapsamındadır: 2-4 hafta, 80.000 - 150.000 ₺. Mevcut sisteme eklenen belge modülü 8.000 - 45.000 ₺ ek modül bandında kalabilir.

İlgili rehberler

• Mobil uygulama seçimi: PWA mı, native mi? Kurumsal saha ve maliyet rehberi
• En iyi yazılım şirketleri 2026: Türkiye'deki kurumsal yazılım firmaları sıralaması
• ERP şartnamesi ve ihtiyaç analizi şablonu 2026: Başarısızlığı önleyen 16 maddelik RFP rehberi

Hizmet sayfası: Kurumsal yazılım hizmeti