Hazır yazılım mı özel yazılım mı: kararı kayıt modeli verir

Hazır ürünle özel yazılım arasındaki kararı, ürünün neyi tek bir kayıt saydığı ile işin neyi tek bir kayıt saydığı belirler. Satılabilir ya da izlenebilir biriminiz ürünün kayıt birimine oturmuyorsa boşluk oradan açılır. Varyantı ayrı fiyat ve ayrı stok tutmayan bir katalogda iki tanım zaten örtüşür; orada hazır ürün doğru cevaptır.

Bu iki tanım örtüşmediğinde açılan boşluk kaybolmuyor. Yapılandırma ekranı bu boşluğu kapatamaz: alan açar, etiket ve akış değiştirir, ama ürünün neyi tek bir kayıt saydığına dokunmaz. Kapanmayan boşluk başka bir yere düşüyor: bir cihaza, bir baskıya ya da birinin elle tuttuğu ikinci bir deftere.

Hazır ürünün kendi kayıt modeli var

Parfüm perakendesi düğümü tek cümlede gösteriyor. Standart e-ticaret ürün modeli bir ürünü bir kayıt varsayar. Kokudankokuya mağazasında satılabilir birim koku değil hacim, çünkü aynı koku birden çok hacimde satılıyor.

Hazır bir kurulumda bu düğümün iki çıkışı var ve ikisi de tutmuyor. Her hacmi ayrı ürün açarsanız katalog aynı kokunun tekrarıyla şişer; müşteri listede aynı adı arka arkaya görür, listeleme kendi kendini boğar. Hepsini tek ürün altında toplarsanız hacim bazlı stok ve fiyat takibi kaybolur; hangi şişe boyunun tükendiğini kayıttan okuyamazsınız. Yapılandırma ekranı burada size bir varyant alanı verir, ama varyantın satılabilir birim olup olmadığını söyleyemez.

Sınırı hacim düzeyinde çizdik. Koku tek ürün kaydı olarak duruyor. Hacimler o kayda bağlı, kendi stoğunu ve kendi fiyatını taşıyan ayrı satılabilir birimler. Yeni bir hacim eklemek yeni bir ürün açmıyor, mevcut kaydın altına bir birim ekliyor.

Kayıt modeli stoğun yanında gezinmeyi de belirliyor. Kategori ağacının yanına koku ailesi ve nota ikinci bir gezinme ekseni olarak kuruldu. Bir parfüm birden çok notaya bağlanabiliyor, tek bir kategori dalına hapsolmuyor. Marka adını bilmeyen müşteri koku karakterinden başlıyor ve ürüne oradan iniyor. İşin gezinme birimi de kayıt modelinin parçası: bir şeyi neye göre bulduğunuz, neyi bir kayıt saydığınıza bağlı.

Bu düğümün olmadığı bir mağazada karar tersine döner. Ürününü tek biçimde satan, varyantı ayrı fiyat ya da ayrı stok taşımayan bir katalogda standart ürün modeli işin kayıt birimiyle zaten örtüşür; orada sınırı yeniden çizmek yalnızca bakım yükü ekler. Kokudankokuya’da sınırı taşımaya değer kılan şey, hacim başına ayrı stok ve ayrı fiyatın gerçekten tutulması gerekmesiydi.

Kural ürünün kodunda mı, sizin tanımınızda mı

Örtüşmezlik her zaman veri modelinde durmuyor. Bazen kuralda, bazen markada duruyor.

Hazır panel satın alan kurum yazılımın markasıyla görünür; öğrenci giriş ekranında kendi kurumunun değil ürünün adını okur. Vipkurum çatısında istenen bunun tersiydi: 7 kurum kendi alan adından giriyor, kendi markasıyla görünüyor, çekirdek tek kalıyor. Öğrenci, veli ve ödeme kaydı kiracının sınırını geçmiyor; bir kurumun kaydı komşu kuruma görünmüyor. Yeni kurum eklemek ayrı bir kurulum açmıyor, yeni bir kiracı tanımı oluyor.

Kiracı sınırının nerede durduğu belirleyici. Sınır arayüzde bir filtre olarak dururken de sistem çalışıyor görünür; ama filtreyi unutan tek bir rapor komşu kurumun verisini gösterir. Burada sınır veri modelinin içinde duruyor: kayıt yazıldığı anda hangi kuruma ait olduğu belli oluyor, sonradan sorulan bir soru olmuyor.

İkinci örtüşmezlik değerlendirme kuralındaydı. Kural ürünün koduna gömülüyse kurum kendi ölçütünü tanımlayamaz; ölçüt her değiştiğinde bir kod değişikliği ve bir sürüm bekler. Burada değerlendirme türünü kurumun kendisi tanımlıyor. Avrupa ölçütüyle Türkiye ölçütü aynı sınav kaydında yan yana durabiliyor, çünkü ölçüt ürünün kodunda değil kurumun tanımında.

Alternatif neydi ve neden seçilmedi: her kurum için ayrı kurulum. Ayrı veritabanı, ayrı sürüm, ayrı yükseltme takvimi. Bu düzen ilk kurumda ucuz görünür, kurum sayısı arttıkça bakım tek başına bir işe dönüşür. Tek çekirdek kararı ilk kurum yazılırken alındı. Sonradan alınsaydı çoktan yazılmış her kaydın sahibini yeniden tanımlamak gerekirdi.

Rol seti de aynı yerden çıkıyor. Öğretmen, veli ve yönetici aynı ders programı kaydına kendi yetkisi kadar erişiyor. Ders programı, sınıf, şube, sınav ve ödeme tek veri modelinde duruyor. Hazır bir üründe rol seti sabittir; kurumun kendi iş bölümü o sabit sete uymuyorsa, uymayan kısım yine birinin elinde kalır.

Hazır seçenek yazılım değil, bir cihaz olduğunda

Bazı işlerde hazır olan seçenek yazılım bile değil. Bir cihaz. Cihazın maliyeti faturada görünür; asıl bedel cihazın sürece koyduğu sınırda durur.

Optik okuma böyle bir iş. Cihaz tek merkezde durur; şube sınav formlarını oraya taşır ve sonuç için sıra bekler. Cihazın arızalandığı gün bütün kurumun değerlendirmesi olduğu yerde durur. Daha sessiz bedel şu: cihazın kabul ettiği formun dışına çıkılamıyor. Form düzeni değiştiğinde çözüm bir tedarik meselesine dönüşüyor: yeni okuyucu alınıyor ya da özel form bastırılıyor, yazılım tarafında karşılığı bulunmuyor.

Optik form okuma aracında okumayı cihazın optiği değil, form görüntüsü üzerindeki görüntü analizi yapıyor; işi Python tarafında OpenCV yürütüyor. Formlar sıradan bir tarayıcıdan yükleniyor. Şube kendi sınavını kendi okutuyor, formlar merkeze taşınmıyor. Form düzeni değiştiğinde uyum yazılımda yapılıyor.

Cihazın kendisi her koşulda yanlış seçim değil. Form düzeninin yıllarca değişmediği ve okumanın tek merkezde toplandığı bir kurumda cihaz ucuz cevaptır. Vipkurum’da koşullar tersineydi: şubeler kendi sınavlarını yapıyor ve form düzeni kurumun kendi değerlendirme tanımına göre değişiyor. Adımı yazılıma çeviren şey teknoloji tercihi değil, bu iki koşuldu.

Şantiyede hazır olan seçenek PDKS turnikesi. Saha geçici olduğu için kurulan donanım sökülmek üzere kuruluyor; kurulum bedeli tek bir sahanın ömrüne bölünüyor. Üstelik personel sahalar arasında dolaştığından tek noktaya bağlı kayıt zaten tutmuyor.

Şantiye personel takibinde QR kod kimin okuttuğunu, konum hangi sahada olduğunu belirliyor; iki bilgi tek giriş kaydında birleşiyor ve saha adı elle seçilmiyor. Hak ediş ayrı bir hesap tablosunda tutulmuyor, eşleşen giriş-çıkış çiftlerinden üretiliyor; çıkışı okutulmamış bir giriş eksik kayıt olarak duruyor ve itiraz edildiğinde dayanak o kayıt oluyor. Şantiye kapandığında sökülecek donanım kalmıyor, sistem personelin telefonunda duruyor.

Basılı olan her şey de bir donanım adımıdır

Donanım adımı her zaman bir cihaz değil. Basılı materyalde içerik taşıyıcısına mühürlenir: kâğıt baskıdan çıktığı anda üzerindeki bilgi donar. Fiyat değişirse, unvan değişirse, donanım listesi güncellenirse yapılacak iş bir kayıt güncellemesi değil, yeni bir baskıdır. Süreç tıpkı optik okuyucuda ya da turnikede olduğu gibi orada bekler ve orada para harcar.

Showroomda bu adım net görünüyor. Sergilenebilen araç sayısı fiziksel olarak sınırlı; yoğun saatte müsait danışman sayısı da sınırlı. Basılı broşür bu boşluğu kapatır, ama her fiyat ya da donanım güncellemesi yeniden basım demektir. SsangYong showroom kiosk uygulamasında donanım bilgisi güncellendiğinde broşür basılmıyor; içerik aynı kod tabanından mağaza cihazlarına iniyor. Uygulama ziyaretçinin telefonunda değil mağazanın cihazında çalışıyor: indirme adımı, hesap açma adımı ve kişisel veri bırakma adımı yok. Arayüz ekranı ilk kez gören, ayakta duran ve acelesi olan kişiye göre kuruldu.

Aynı adım kasap tezgâhında da var. Basılı menü her fiyat değişiminde yeniden baskı demek; menü bir kez laminatlandığında fiyat da laminatlanır. Çatalca Merkez Kasap’ın QR menüsünde menü metin olarak duruyor. Fiyat değiştiğinde sayfa güncelleniyor ve aynı QR kod, yeni baskı olmadan güncel menüyü açıyor. Menü bölümlere ayrıldı ve her bölüm kendi adresini taşıyor; farklı masa ve vitrin QR’ları aynı sayfanın farklı noktasına iniyor.

Kartvizit aynı sorunun en küçük hâli. Kart bir kez basılır, ama işletme değişmeye devam eder: telefon değişir, unvan değişir, adres eskir. QRVizit’te kurduğumuz ayrım şu: kod kalıcı, içerik değişebilir. Karta basılan QR kodun adresi bir kez sabitleniyor, arkasındaki tanıtım sayfası panelden güncelleniyor; bilgi değiştiğinde kartlar yeniden basılmıyor. QRVizit geliştirme aşamasında, bu ayrım üzerinde hâlâ çalışıyoruz.

Baskı adımının bedeli matbaa faturasıyla bitmiyor. Yeniden basım kararı verilene kadar sahadaki materyal eski fiyatı taşımaya devam eder; danışman broşürdeki rakamın yanına sözlü bir not ekler ve güncel bilgi yine bir insanın hafızasında durur.

Basılı materyal süreçte hiçbir güncelleme taşımıyorsa baskı bir donanım adımı olmaz. Tek seferlik bir davetiye ya da tarihi geçince hükmü kalmayan bir duyuru böyledir: içerik zaten dondurulmak üzere basılır. Ölçüt şu: kâğıt basıldıktan sonra üzerindeki bilgi değişiyor mu?

Elle tutulan ikinci defter

Hazır ürün bir kaydı tutmadığında o kayıt yok olmuyor. Bir insan tutuyor. Hata da tam orada giriyor, çünkü ikinci defter ilkinden habersiz.

Öğretmen soruları görüntü düzenleyicide kırpıyor, cevap anahtarını ayrı bir belgeye elle yazıyor. Anahtarda tek satır kaydığında sınavın tamamının değerlendirmesi yanlışa dönüyor ve yanlış, sonuçlar dağıtılana kadar görünmüyor. Soru kırpma aracında cevap anahtarı ayrı belge olmaktan çıkıp kırpılan sorunun kendi kaydına giriyor. İş bilerek bölündü: sayfadan soruyu ayırmak görüntü işlemenin işi, cevabı soruya bağlamak dil modelinin işi. Kırpma sınırları modelin yorumuna bırakılsaydı soru sınırları güvenilmez olurdu. Elde olmayan bir soru gerektiğinde mevcut örneklerden üretiliyor ve cevabı aynı kayda yazılıyor; anahtar için ayrı bir belge açılmıyor.

Aynı desen üretim tarafında da var. Resterm’in ısıtıcı seçim yazılımından önce hesap bir tabloda, katalog bir dosyada, teklif üçüncü bir yerde tutuluyordu. Seçim ile teklif kalemi koptuğunda hangi kalemin hangi hesaba dayandığı sonradan okunamıyordu; müşteri “bu rakam nereden çıktı” diye sorduğunda cevap birinin hafızasında kalıyordu. Yazılımı Resterm’in kendi ürün yapısı üzerine kurduk; genel amaçlı bir teklif aracına katalog eklemek hesabı teklif kalemine bağlamıyordu.

Klinikte defter takvimin kendisiydi. Genel amaçlı randevu yazılımı saati tutuyor, tedavi planının hangi adımında olunduğunu tutmuyor. Plan takvimden, fatura defterden, ay sonu tablosu üçüncü bir yerden çıkıyordu. Diş kliniği CRM’inde tedavi planı kendi başına duran bir kayıt: diş bazında kuruluyor, seanslara bölünüyor ve her randevu planın belirli bir adımına bağlanıyor. Plan değiştiğinde takvim de kayıyor; hiçbir randevu boşta kalan bir kayıt olmuyor. Fatura hasta kaydından çıkıyor.

Elle tutulan defter görünmez olduğu için kimse onu bir sistem saymıyor; ay sonunda bir sayı tutmadığında da kimse nereye bakacağını bilmiyor. Bulmanın kısa bir yolu var: aynı bilginin sisteme girildikten sonra bir kez daha yazıldığı yeri arayın. Cevap anahtarı, teklif kalemi ve ay sonu tablosu aynı yerden çıkıyor; ürünün tutmadığı kayıt kendine bir defter buluyor.

Cevabın boyutunu kısıt belirler

Buraya kadarki örnekler yazmayı işaret ediyor. Aynı portföyde tersini gösteren işler de var: kısıt bazen yazmamayı, bazen küçük yazmayı söylüyor.

KGM SsangYong’un kurumsal sitesi zaten yayındaydı. Gelen iş yeni site yazmak değil, ayakta duran siteyi hafifletmekti. Kod tabanını önce okuduk, çalışan bölümlere dokunmadık; müdahale sayfa yükünü taşıyan yerlerle sınırlı kaldı. Müdahalenin kendisi somuttu. Araç görselleri tek bir adlandırma ve klasör düzenine taşındı; hangi modelin hangi dosyayı kullandığı kod okunmadan görülüyor. Katalog okumaları Redis önbelleğinden karşılanıyor; aynı sorgu her sayfa açılışında MySQL’e düşmüyor, MySQL yalnızca veri değiştiğinde devreye giriyor. Teknoloji kararını bakımın kimde kalacağı belirledi: mevcut Laravel, Tailwind ve jQuery setinin dışına çıkılmadı; yığına eklenen tek parça önbellek katmanı oldu.

Öbür durum yazmak, ama küçük yazmak. Çatalca Merkez Kasap’ta kısıt menüyü okuyan kişinin durduğu yerdi: masada, kendi telefonunda, işletme içindeki zayıf bağlantıda, birkaç saniyede karar veriyor. Menü Vue 3 ile tek sayfa kuruldu; bir kez açıldıktan sonra bölümler arası geçiş yeni sayfa isteği açmıyor. Sipariş, ödeme ve stok katmanı yok; açılışı geciktiren bağımlılık da yok. Portföyümüzün en küçük web yazılımı işi orası.

Kokudankokuya da aynı yerden bakıyor. Kataloğun ölçeği ayrı bir arama ya da önbellek katmanı gerektirmedi; mağaza Laravel ve MySQL üzerinde duruyor, taşınacak parça sayısı az. Özelleşen şey kayıt modeli; altyapının da özelleşmesi gerekmiyor.

Bu iki iş aynı ölçütün iki yönü. Birinde kısıt mevcut kod tabanı ve onu sürdürecek ekipti; ötekinde menüyü okuyanın telefonu ve bağlantısı. İkisinde de cevabın boyutunu kısıt belirledi.

Yazdıracağınız şeyi kimin sürdüreceği, yığın kararını sizin yerinize veriyor.

Kararı gerçekten veren sorular

Karar beş soruyla veriliyor.

İşinizin satılabilir ya da izlenebilir birimi, ürünün kayıt birimiyle aynı mı? Parfümde birim hacim, klinikte tedavi planı. İkisi de standart ürün ya da randevu kaydına oturmuyor.

Kuralınız ürünün kodunda mı duruyor, sizin tanımınızda mı? Değerlendirme ölçütü koda gömülüyse her ölçüt değişikliği için sürüm beklersiniz.

Sürecin hangi adımı bir cihazın, bir kâğıdın ya da bir baskının üzerinde duruyor? O adım nerede duruyorsa süreç de orada bekliyor: optik okuyucuda, turnikede ya da broşürün yeniden basımında.

Aynı bilgiyi kim elle ikinci kez yazıyor? Hata o ikinci yazımda giriyor; cevap anahtarında da, teklif kaleminde de.

Yazdıracağınız şeyin bakımını kim sürdürecek? Cevap yığın kararını belirler.

Soruların hepsine “örtüşüyor, kimse elle tutmuyor, hiçbir adım kâğıtta beklemiyor” diyebiliyorsanız hazır ürün doğru cevaptır ve yazılacak bir şey yoktur.

Örtüşmüyorsa boşluğu kapatan şey yapılandırma değil, kaydın kendisini yeniden tanımlamaktır. Bu soruları kendi süreciniz üzerinde birlikte yürütmek isterseniz, yazılım danışmanlığı tarafında masaya ilk koyduğumuz iş budur.