PDF'ten baskıya: dosya doğrulama otomasyonunun incelikleri

Bir kartvizit ekranda kusursuz görünür. Müşteri PDF'ini yükler, önizlemede her şey yerli yerindedir, siparişi onaylar. Üç gün sonra kutu açıldığında kartvizitin kenarında ince beyaz bir çizgi belirir — tasarım kağıdın kenarına kadar gitmemiştir, çünkü dosyada taşma payı yoktu. Matbaacılıkta en pahalı hata budur: kusur üretimden sonra fark edilir, "suç kimde" tartışması başlar ve iş çoğu zaman ücretsiz yeniden basılır. MatbaaStore'da bu senaryoyu ortadan kaldıran şey ne müşterinin dikkati ne de operatörün gözü oldu; dosya doğrulama otomasyonu oldu.

Baskı öncesi kontrol — sektörün deyimiyle preflight — geleneksel matbaada tecrübeli bir ustanın işidir. Usta dosyayı açar, ebadına bakar, çözünürlüğünü tahmin eder, taşma payını gözler, renk uzayını yoklar. Bu bilgi bir insanın kafasında yıllarla birikir ve o insan izne çıktığında matbaayla birlikte tatile gider. Biz bu bilgiyi koda döktük: her yüklenen dosyayı, ustanın yaptığı kontrollerin tamamından geçiren, geçemeyenleri anlaşılır bir dille müşteriye açıklayan bir hat kurduk.

Bu yazıda o hattı anlatacağız. Baskı öncesi kontrol listesini yazılıma nasıl çevirdiğimizi, PDF/AI/PSD gibi birbirinden farklı dosyaları tek bir işleme hattında nasıl ehlileştirdiğimizi, müşteriye tam olarak basılacak şeyi gösteren otomatik önizlemeyi nasıl ürettiğimizi, hangi kontrolü makineye hangisini insana bıraktığımızı ve en önemlisi — hatalı bir dosyada müşteriyi suçlamak yerine ona yol gösteren geri bildirimi nasıl kurguladığımızı tek tek ele alacağız.

Baskı öncesi kontrol listesini yazılıma dökmek

İlk işimiz, ustanın kafasındaki kontrol listesini yazıya geçirmekti. Bu liste sanıldığından uzundur ve maddelerin hepsi eşit ağırlıkta değildir. Bir kısmı üretimi fiziksel olarak imkânsız kılan sert kurallardır; bir kısmı sonucu bozma ihtimali olan ama müşterinin bilerek tercih etmiş olabileceği yumuşak uyarılardır. Bu ayrımı en baştan yapmak, sonradan onlarca "neden siparişim engellendi" şikâyetinden bizi kurtardı. İşte hattımızın kontrol ettiği temel maddeler:

• Ebat uyumu: dosyanın gerçek sayfa boyutu, sipariş edilen ürün ebadıyla milimetre toleransında eşleşmeli. 85×55 mm kartvizit siparişine gelen A4 dosya, çoğu zaman yanlış şablonda çalışıldığının işaretidir. Toleransı ±0,5 mm tuttuk; altındaki farkları sessizce ölçekleyip düzeltiyoruz, üstündekileri engelliyoruz.
• Çözünürlük: baskıda hedef 300 DPI'dır. Dosyadaki raster görsellerin efektif çözünürlüğünü — yani ölçeklendikten sonraki gerçek piksel yoğunluğunu — tek tek ölçüyoruz. 150 DPI altı sert engel, 150–250 DPI arası "baskıda pikselleşebilir" uyarısı, üstü temiz geçiş.
• Taşma payı (bleed): kenara basan her tasarım, kesim kaymasına karşı her kenardan 3 mm dışa taşmalı. Taşma payı yoksa ya da yetersizse en sık karşılaştığımız hata bu — ilk yüklemelerin neredeyse beşte biri buradan takılıyor.
• Güvenli alan: yazı ve logo gibi kesilmemesi gereken öğeler, kesim çizgisinin en az 3 mm içinde kalmalı. Kenara yapışık telefon numarası, kesimde yarısı gidebilecek bir risktir.
• Renk uzayı: baskı CMYK'dır, ekran RGB. RGB gelen bir dosya baskıda beklenenden donuk çıkar; özellikle canlı maviler ve yeşiller. Belge ve içindeki her nesnenin renk uzayını denetliyoruz.
• Font gömme: dosyadaki tüm yazı tipleri PDF'e gömülü (embedded) olmalı. Gömülü olmayan font, bizim sunucumuzda o font kurulu değilse başka bir yazı tipiyle değişir ve tasarım bozulur. Alternatifi yazıları eğriye çevirmektir (outline).
• Toplam mürekkep miktarı: CMYK kanallarının toplamı (TAC) belirli bir eşiği aşarsa — kuşe kağıtta 300, kraft gibi emici kağıtta daha düşük — mürekkep kurumaz, arka yüze bulaşır. Koyu siyah zeminlerde sık rastlanan sessiz bir tuzaktır.

Bu maddeleri koda dökerken en isabetli kararımız, her kontrolü ortak bir arayüz arkasına koymak oldu. Her kontrol tek bir belgeyi alır, tek bir bulgu döndürür; hattın kendisi hangi kontrollerin çalışacağını bilmez, sadece listeyi gezer. Böylece yeni bir kontrol eklemek, hatta çıkarmak, mevcut hiçbir şeye dokunmadan tek bir dosya yazmak demek oldu.

type Kontrol interface {
    Ad() string
    Calistir(d *Dokuman) Bulgu
}

type Bulgu struct {
    Gecti   bool
    Seviye  Seviye   // Engelleyici | Uyari | Bilgi
    Mesaj   string   // operatöre ve loga
    Cozum   string   // müşteriye rehberli öneri
    OtoFix  bool     // otomatik düzeltilebilir mi
}

Seviye alanını üç kademeye ayırmak, hattın karakterini belirledi. Engelleyici bulgular siparişi durdurur; uyarılar müşteriye gösterilir ama devam etmesine izin verir; bilgi seviyesindekiler yalnızca operatör konsoluna düşer. Bu üçlü sayede aynı motor hem "bu dosya basılamaz" diyebiliyor hem de "basılır ama sonuç senin beklediğin gibi olmayabilir" diyebiliyor — ki bu ikisini karıştıran preflight sistemleri müşteriyi ya boğar ya da yanıltır.

Listenin göründüğünden derin olduğunu söylemiştik; bir örnek, bu maddelerin altındaki gizli tuzaklardır. Örneğin siyah tek bir renk değildir. Küçük bir yazıyı "zengin siyah" (dört kanalın da açık olduğu C:60 M:40 Y:40 K:100 gibi bir karışım) ile basmak, en ufak baskı kaymasında kenarlarda renkli hayaletler yaratır; bu yüzden küçük punto metinlerde saf K:100 dışına çıkan siyahları uyarıya dönüştürüyoruz. Aynı şekilde overprint (üstüne baskı) ayarı yanlış bırakılmış beyaz bir nesne baskıda tamamen görünmez olur — ekranda duran logo, kağıtta yok olur. Bu tür ayarları dosyanın grafik durumundan (graphics state) okuyup, sessiz felaketleri sessiz kalmadan yakalıyoruz.

Bir başka incelik spot renkler. Kurumsal müşteriler markalarının Pantone rengini ister; ama sipariş dört renk (CMYK) baskıysa, o spot renk baskıda en yakın CMYK karşılığına düşer ve çoğu zaman tam tutmaz. Dosyada tanımlı spot renkleri ayıklayıp, siparişin baskı yöntemiyle karşılaştırıyoruz: beşinci renk olarak Pantone basılacak bir işse renk korunur, değilse "markanızın Pantone 485 rengi CMYK'da yaklaşık karşılığıyla basılacak" uyarısını önizlemede gösteriyoruz. Bu tek uyarı, matbaacılıkta en sık yaşanan "renk tutmadı" itirazlarının önemli bir kısmını daha sipariş anında bitirdi.

PDF, AI ve PSD'yi tek hatta ehlileştirmek

Kontrol listesini yazmak kolay kısımdı. Asıl zorluk, o kontrolleri üç bambaşka dosya türü üzerinde çalıştırmaktı. Müşteri karşımıza PDF, Adobe Illustrator (.ai) ya da Photoshop (.psd) dosyasıyla gelebilir — ve bu üçü, içeriğini bize aynı dille anlatmaz. İşin sırrı, üçünü de mümkün olan en erken adımda tek bir kanonik biçime indirgemekti. O biçim bizim için PDF/X oldu: baskı için standartlaştırılmış, renk uzayı ve font gömme kuralları belli, kendi kendine yeten bir PDF alt kümesi.

Şanslıydık ki AI dosyaları aslında birer PDF'tir; Illustrator kendi verisini bir PDF kabuğunun içine saklar. Bu yüzden .ai dosyalarını çoğu zaman doğrudan PDF motorumuzla açabildik. PSD ise apayrı bir dünya — katmanlı, RGB ağırlıklı, gömülü akıllı nesneler barındıran, yüzlerce megabayta ulaşabilen bir raster formatı. PSD'leri libvips ve ImageMagick zincirinden geçirip düzleştiriyor, CMYK'ya çeviriyor ve tek katmanlı bir çıktıya indiriyoruz. Bu çeviri kayıplı bir işlemdir; bu yüzden PSD yükleyen müşteriye önizlemede "dosyanız düzleştirildi, katmanlarınız korunmadı" bilgisini açıkça veriyoruz.

PDF tarafında motor olarak Ghostscript ve pdfium'u birlikte kullandık: pdfium hızlı raster önizleme ve sayfa geometrisi için, Ghostscript ise renk dönüşümü, PDF/X normalizasyonu ve font gömme denetimi için. İkisinin çıktısını Go tarafında bir Dokuman nesnesinde birleştiriyoruz — sayfa kutuları (MediaBox, TrimBox, BleedBox), gömülü fontların listesi, her nesnenin renk uzayı, raster görsellerin efektif DPI'ı. Kontroller artık ham dosyaya değil, bu normalize edilmiş nesneye bakıyor; PDF mi PSD mi geldiğini umursamıyorlar.

Farklı biçimleri kontrollerin içinde ayrıştırmaya kalkarsanız, her yeni kontrol her formatı yeniden öğrenmek zorunda kalır. Çeviriyi hattın en başına koyun; kontroller tek bir dünya görsün.

Bu hattın gözden kaçan ama kritik bir boyutu güvenlik. Yüklenen dosya, tanımı gereği güvenilmez bir girdidir; internetteki en karmaşık ve en çok istismar edilen biçimlerden biri PDF'tir. Dönüştürme adımlarının tamamını izole Docker konteynerlerinde, ağ erişimi kapalı ve kaynak sınırları dayatılmış worker'larda çalıştırıyoruz. Bozuk ya da kötü niyetli bir dosya bir worker'ı çökertse, o worker ölür, iş kuyruğa geri döner, hattın geri kalanı etkilenmez. Ayrıca her dönüşüme katı bir süre ve bellek tavanı koyduk — 200 MB'lık bir PSD'yi açmaya çalışırken belleği tüketen bir sürecin bütün makineyi kilitlemesini istemiyorduk.

Normalize edilmiş belge üzerinde bir de yapısal ayrım yapıyoruz: hangi öğe vektör, hangisi raster. Bu ayrım çözünürlük kontrolünün doğru çalışması için şart, çünkü vektör bir logonun DPI'ı yoktur — sonsuza kadar keskindir, onu piksel yoğunluğuyla ölçmek anlamsızdır. DPI kontrolünü yalnızca raster nesnelere uygularken, saç teli inceliğindeki çizgiler (hairline) için ayrı bir kural işletiyoruz: 0,25 puntonun altındaki çizgi kalınlıkları bazı baskı yöntemlerinde hiç basılmaz ya da kopar; bunları uyarıya çeviriyoruz. Ham dosyayı tek bir soyut nesneye indirmenin kazancı burada net görülüyor — bu iki farklı kural, aynı normalize edilmiş belgenin farklı yüzlerine bakıyor, dosyanın PDF mi PSD mi olduğunu hiç sormadan.

İşleme hattını senkron tutmadık. Müşteri dosyayı yüklediği an sipariş akışı beklemeye girmez; dosya bir Redis kuyruğuna atılır, Go worker'ları sırayla alır. Tipik bir kartvizit PDF'i saniyenin altında, ağır bir katalog ya da dev bir PSD birkaç saniyede işlenir. Müşteri arayüzü bu sırada "dosyanız kontrol ediliyor" durumunu gösterir ve iş bitince sonucu canlı olarak günceller. Bu asenkron tasarım, kampanya dönemlerinde yüzlerce dosyanın aynı anda gelmesini bir sorun olmaktan çıkardı — worker sayısını artırmak yetiyor.

Otomatik önizleme: müşteriye tam olarak basılacak şeyi göstermek

Preflight'ın yarısı kontrol etmekse, diğer yarısı göstermektir. Bir müşteriye "taşma payınız yok" demek soyut bir uyarıdır; ona kesim çizgisini, taşma alanını ve güvenli bölgeyi üst üste bindirilmiş bir görselde göstermek ise anlaşılır bir gerçektir. Bu yüzden her dosya için, kontrol sonuçlarıyla birlikte üç katmanlı bir önizleme üretiyoruz.

İlk katman ham baskı görüntüsü. Normalize ettiğimiz PDF'i 150 DPI'da raster'a çeviriyoruz — ekranda göstermek için 300 DPI gereksiz ağırlık, 150 DPI hem keskin hem hafif. İkinci katman geometrik kılavuzlar: TrimBox'tan kesim çizgisini, BleedBox'tan taşma sınırını, içeriden 3 mm çekerek güvenli alanı çiziyoruz. Müşteri bu overlay'de logosunun güvenli alanın dışına taştığını kendi gözüyle görüyor. Üçüncü katman soft-proof: CMYK simülasyonu. Ekran RGB olduğu için, baskıda renklerin nasıl donacağını bir ICC profili üzerinden simüle edip gösteriyoruz; böylece müşteri "ekranda daha canlıydı" sürprizini üretimden önce yaşıyor.

Önizleme üretimini bilerek kontrollerden ayrı tuttuk ama aynı normalize edilmiş Dokuman nesnesini paylaşıyorlar. Kontrol motoru taşma payının yetersiz olduğunu tespit ettiğinde, önizleme katmanı tam o eksik bölgeyi kırmızıyla boyuyor — yani teşhis ve görsel kanıt aynı kaynaktan geliyor, birbirini asla yalanlamıyor. Bu tutarlılık önemliydi; müşteriye "hata var" deyip önizlemede hiçbir şey göstermemek, güveni en hızlı yok eden şeydir.

Çok sayfalı işlerde — bir katalog ya da broşür — her sayfa için ayrı bir önizleme ve ayrı bir bulgu kümesi üretiyoruz. Kontroller sayfa bazında çalıştığı için, müşteri "12. sayfadaki görsel düşük çözünürlüklü" gibi hedefli bir uyarı alıyor, koca dosya için belirsiz bir "sorun var" mesajı değil. Bu ayrıntı, çok sayfalı işlerde düzeltme süresini kısalttı; müşteri neyi nerede düzelteceğini biliyor.

Önizlemeleri de önbelleğe aldık. Aynı dosya tekrar tekrar açıldığında raster'ı yeniden üretmek anlamsız; ürettiğimiz görselleri dosya içeriğinden türettiğimiz bir hash anahtarıyla saklıyoruz. Müşteri siparişini gözden geçirirken sayfayı beş kez açsa da önizleme diskten anında geliyor. Bu, hem sunucu yükünü sabit tuttu hem de arayüzü hızlandırdı. Müşteri dosyayı düzeltip yeniden yüklediğinde ise içerik hash'i değiştiği için yeni bir sürüm oluşuyor; eski önizleme ve bulgular kayda geçiyor, operatör hangi sürümün onaylandığını sonradan görebiliyor. Baskı sonrası çıkan "ben bunu göndermemiştim" tartışmalarında bu sürüm izi, kimin neyi onayladığını net gösteren bir kayıt oldu.

Sert kural, yumuşak uyarı: otomasyon ile insan onayının dengesi

Yıllar bize şunu öğretti: preflight'ı tam otomatik yapmaya kalkan herkes, er ya da geç, teknik olarak "temiz" ama içerik olarak felaket bir işi basar. Yazımı yanlış bir başlık, yanlış telefon numarası, müşterinin fark etmediği eski logo — bunların hiçbiri DPI ya da renk uzayı kontrolüne takılmaz. Makine dosyanın basılabilir olduğunu doğrular; dosyanın basılması gerekeni içerdiğini doğrulayamaz. Bu ayrım, otomasyon sınırımızı çizdi.

Kararımız şu oldu: makine elinden gelen her nesnel kontrolü yapar ve sonucu üç kovaya ayırır. Engelleyici bulgular varsa iş operatöre bile gitmez, doğrudan müşteriye döner — çünkü basılamayacak bir dosyayı bir insanın incelemesi zaman kaybıdır. Yalnızca uyarı seviyesinde bulgular varsa ya da her şey temizse, iş bir operatör konsoluna düşer. Orada operatör, makinenin çıkardığı önizleme ve bulgu listesiyle donatılmış hâlde, saniyeler içinde son gözü atar. Onay tuşuna basan hâlâ bir insandır.

Bu denge bize iki dünyanın iyisini verdi. Otomasyon, işlerin büyük çoğunluğundaki mekanik kontrolü — ki en yorucu ve en çok hata yapılan kısım budur — üstlendi; operatör ise yalnızca insan yargısı gerektiren son adıma, üstelik makinenin hazırladığı tam bilgiyle odaklandı. Bir operatörün bir işi onaylaması dakikalar değil saniyeler sürmeye başladı, çünkü artık dosyayı sıfırdan inceliyor değil, makinenin raporunu doğruluyordu.

Rakamlar bu dengenin işe yaradığını gösterdi. İlk yüklemelerin kabaca beşte biri en az bir engelleyici bulguyla geri dönüyor — ezici çoğunluğu taşma payı ve renk uzayı. Bu işler operatörün masasına hiç uğramadan, ortalama bir işlem gecikmesiyle müşteriye geri gidiyor; yani en sık hataları yakalamak için hiçbir insan mesaisi harcanmıyor. Temiz gelen ya da yalnızca uyarı taşıyan işlerdeyse operatörün onay süresi, önizleme ve bulgu raporu hazır geldiği için işi elle açıp incelemenin çok altına indi. En anlamlı ölçüm ise dolaylıydı: dosya hatası kaynaklı yeniden baskılar, hattı devreye aldıktan sonra belirgin biçimde azaldı — çünkü hataların büyük kısmı artık kağıda değil, ekrana düşüyor.

func (h *Hat) Degerlendir(d *Dokuman) Sonuc {
    var bulgular []Bulgu
    for _, k := range h.kontroller {
        b := k.Calistir(d)
        if !b.Gecti {
            bulgular = append(bulgular, b)
        }
    }

    // Tek bir engelleyici bulgu, işi doğrudan müşteriye geri yollar.
    if enAgir(bulgular) == Engelleyici {
        return Sonuc{Durum: MusteriyeDon, Bulgular: bulgular}
    }
    // Aksi halde: temiz ya da yalnızca uyarı — insan onayına.
    return Sonuc{Durum: OperatoreGonder, Bulgular: bulgular}
}

Burada bir anti-pattern'den özellikle kaçındık: "yeterince yüksek güvenle otomatik onayla" cazibesi. Bazı işleri hiç insana göstermeden basma fikri kağıt üzerinde verimli görünür, ama matbaada bir yanlış baskının maliyeti, bir operatörün birkaç saniyesinden çok daha yüksektir. Yeniden baskı sadece kağıt ve mürekkep değil; kaybedilen üretim slotu, geciken teslimat ve zedelenen güvendir. İnsan onayını hattan çıkarmadık çünkü matematiği tutmuyordu.

Hatalı dosyada müşteriyi suçlamak değil, yol göstermek

Preflight sistemlerinin çoğu teknik olarak doğru, insani olarak berbat bir iş çıkarır: "Dosya doğrulama başarısız. Hata kodu: BLEED_MISSING." Bunu okuyan müşteri ne olduğunu anlamaz, ne yapacağını bilmez ve telefona sarılır — otomasyonun ortadan kaldırması gereken telefon trafiği tam da buradan geri döner. Bizim için hattın en değerli kısmı, kontrol motoru değil, bulguları müşterinin diline çeviren geri bildirim katmanı oldu.

Her bulgunun yanında üç şey bulunuyor: ne yanlış, neden önemli ve nasıl düzeltileceği. "Taşma payı eksik" demiyoruz; "Tasarımınız kağıdın kenarına kadar gidiyor ama 3 mm taşma payı yok. Kesim sırasında oluşabilecek milimetrelik kaymalar kenarda beyaz çizgi bırakabilir. Tasarımınızı her kenardan 3 mm dışa taşırın ya da aşağıdaki 'otomatik ekle' seçeneğini kullanın" diyoruz. Fark, müşteriyi hatasıyla baş başa bırakmakla elinden tutmak arasındaki farktır.

Bir adım daha attık: düzeltilebilir hataları otomatik düzeltmeyi teklif ettik. Bulgu nesnesindeki OtoFix bayrağı işte bunun için. Bazı sorunların nesnel ve güvenli bir çözümü vardır ve bunları müşteriyi tasarım programına geri göndermeden halledebiliriz:

• RGB'den CMYK'ya dönüşüm: renk uzayı yanlışsa, standart bir baskı profiliyle dönüştürüp müşteriye "öncesi/sonrası" önizlemesini gösteriyoruz. Onaylarsa dönüştürülmüş dosya siparişe geçiyor.
• Taşma payı ekleme: kenardaki içerik ayna yansımasıyla ya da düz renk uzatmasıyla 3 mm dışa taşırılabiliyorsa, öneriyi sunuyoruz. Riskli durumlarda (kenara yapışık metin gibi) otomatik düzeltmeyi kapatıp elle müdahale istiyoruz.
• Font gömme / eğriye çevirme: gömülü olmayan fontları, dosyada mevcutsa gömüyor; değilse müşteriyi yazıları outline'a çevirmeye yönlendiriyoruz.
• Küçük ölçek düzeltmesi: ebat tolerans içinde küçük bir sapma gösteriyorsa, orantıyı bozmadan hedef ebada ölçekleyip bilgi olarak bildiriyoruz.

Kritik ilke şu: otomatik düzeltme asla sessizce olmaz. Her düzeltmenin öncesi ve sonrası önizlemede yan yana durur, karar müşteriye aittir. Çünkü bir tasarımcının bilerek RGB'de bıraktığı, bilerek kenara yapıştırdığı bir öğe olabilir; makinenin "düzelttiğini" sandığı şey, müşterinin niyetini bozabilir. Otomasyonun müşteri adına değil, müşteriyle birlikte karar verdiği yer burasıdır.

İyi bir hata mesajı kullanıcıyı suçlamaz; onu bir sonraki doğru adıma taşır. Preflight'ın değeri kaç hatayı yakaladığında değil, kaç hatayı müşterinin kendi başına çözmesini sağladığında ölçülür.

Bu yaklaşımın ölçülebilir sonucu, dosya kaynaklı destek taleplerinin çökmesi oldu. Eskiden "dosyam neden kabul edilmedi" diye açılan konuşmaların çok büyük kısmı, artık müşterinin arayüzdeki rehberli mesajı okuyup kendi başına çözmesiyle hiç açılmıyor. Telefonla teklif devrini bitiren fiyatlandırma motoruysa, telefonla dosya sorunu devrini bitiren de bu geri bildirim katmanı oldu.

Sonuç

Dosya doğrulama otomasyonunu işe yarar kılan, tek bir zekice algoritma değildi; üç sıradan disiplinin toplamıydı. Birincisi, ustanın kafasındaki kontrol listesini sert ve yumuşak diye ayrıştırıp her kontrolü ortak bir arayüz arkasına koymak. İkincisi, PDF, AI ve PSD'yi hattın en başında tek bir kanonik biçime indirip kontrollerin tek bir dünya görmesini sağlamak. Üçüncüsü — ve en çok ihmal edileni — makinenin bulgularını müşteriyi suçlayan bir hata koduna değil, elinden tutan bir yönergeye çevirmek.

Otomasyonun sınırını da net çektik: makine dosyanın basılabilir olduğunu kanıtlar, basılması gerekeni değil. Bu yüzden insan onayını hattan çıkarmadık; onun yerine operatörü, makinenin hazırladığı tam bilgiyle donatıp işini saniyelere indirdik. Kurmayı düşündüğünüz her doğrulama hattında önce şu soruyu sorun: bu kontrolün sonucunu kim, nasıl bir dille görecek? Çünkü bir preflight sisteminin gerçek başarısı, yakaladığı hataların sayısında değil, o hataları kullanıcının sakin bir şekilde çözebilmesindedir. Kontrolleri yazmak kolaydır; asıl ustalık, "hayır" demeyi bilen ama nedenini nazikçe anlatan bir sistem kurmaktır.