Raporun altındaki katmanı kurarız: kaynak sistemlerden ETL veya ELT ile veri çekilir; ham, işlenmiş ve sunum katmanlarında modellenir; geçmişiyle birlikte saklanır. Metrik tanımları tek bir veri sözlüğünde sabitlenir, kalite kontrolleri sessiz bozulmaları daha yükleme sırasında yakalar.
Bir işletmede aynı soruya iki farklı sayı gelmesi neredeyse kural gibidir. Geçen ay kaç ton sevk edildiği sorulduğunda satış bir rakam, üretim başka bir rakam, muhasebe üçüncü bir rakam söyler. Kimse yanlış yapmıyordur; herkes farklı bir kaynaktan ve farklı bir tanımla bakmaktadır. Satış irsaliye tarihini, muhasebe fatura tarihini, üretim ise hattan çıkış tarihini esas alır. Üstüne geçmişe dönük düzeltmeler biner: ERP'de eski bir kayıt güncellendiğinde geçen ayın raporu sessizce değişir ve bir önceki toplantıda konuşulan sayı bir daha bulunamaz. Toplantının yarısı hangi rakamın doğru olduğunu tartışmakla geçer, karar bir sonraki haftaya kalır. Bir süre sonra herkes kendi tablosunu kendi yöntemiyle tutmaya başlar; şirkette tek bir rakam kalmaz, birbirini denetlemeyen birkaç ayrı gerçek olur. Sorun raporlama aracında değil, raporun altındaki katmanın hiç kurulmamış olmasındadır.
İkinci sorun raporun doğrudan canlı sistem üzerinde çekilmesidir. ERP ve üretim veritabanları işlem yapmak için tasarlanmıştır; kayıt açmak, güncellemek ve tek tek sorgulamak için hızlıdırlar. Ay sonunda on iki ayı tarayan bir rapor çalıştırıldığında ise aynı veritabanı yavaşlar ve bunu sahadaki kullanıcı terminal ekranında hisseder. Daha önemlisi, işlem veritabanı geçmişi tutmak zorunda değildir: bir müşterinin unvanı değiştiğinde eski faturalar da yeni unvanla görünür, bir ürünün fiyat grubu güncellendiğinde geçen yılın analizi bugünün grubuyla hesaplanır. Bir de her yeni rapor yazanın aynı tablo birleşimlerini baştan keşfetmesi vardır; üç kişi aynı işi üç farklı yoldan yapar ve sonuçlar birbirini tutmaz. Bu üç sorun ayrı ayrı katlanılabilir görünür; bir arada bulunduklarında raporlamaya duyulan güveni bitirir ve yönetim kararı yeniden sezgiye döner.
Veri ambarı (DWH, data warehouse) bu işi ayrı bir katmana taşır. Kaynak sistemlerden veri düzenli aralıklarla çekilir ve ayrı bir depoda katmanlı biçimde tutulur: ham katmanda veri kaynaktaki hâliyle saklanır, işlenmiş katmanda temizlenir ve ortak tanımlara oturtulur, sunum katmanında ise raporun doğrudan kullanacağı biçimde modellenir. Veriyi önce dönüştürüp sonra yazmaya ETL, önce yazıp ambarın içinde dönüştürmeye ELT denir; hangisinin uygun olduğu kaynağın yapısına ve veri hacmine göre seçilir. Kaynak sistemlerin hiçbiri değiştirilmez; ERP, üretim takip ve muhasebe yazılımı kendi işini yapmaya devam eder, ambar onların yanında ve yalnızca okuma tarafında durur. Ambarın asıl değeri iki şeydedir: tarihi tutar, yani geçen ayın sayısı geçen ayın sayısı olarak kalır; ve metrik tanımlarını tek yerde sabitler, böylece ciro kelimesi bütün raporlarda aynı hesabı ifade eder.
Bu sayfanın söylemediği bir şey kalmasın: veri ambarı kirli veriyi temizlemez, yalnızca görünür kılar. Kaynakta üç kez açılmış bir cari kaydı ambarda da üç kayıttır; bunun çözümü ana veri yönetimidir ve ayrı bir iştir. Ambar tek başına anlık da değildir; hangi verinin ne sıklıkta tazeleneceğine bilerek karar verilir, çünkü her metriği dakikalık tutmak gereksiz maliyet üretir. Ambar panoların da yerine geçmez; panoları, KPI ekranlarını ve rapor dağıtımını anlatan Veri, BI ve Raporlama sayfası bu katmanın üstünde durur ve iki sayfa birlikte okunmalıdır. Ve her firmaya gerekmez: tek bir ERP'niz ve birkaç standart raporunuz varsa ambar kurmak çözdüğünden fazla bakım yükü getirir. Doğru soru veri ambarı kuralım mı değil; kaç kaynaktan, ne kadar geçmişle ve kaç farklı tanımla rapor üretmek zorunda olduğumuz sorusudur. Keşifte önce bunu konuşuruz.
Satış, üretim ve muhasebenin aynı dönem için farklı rakam söylediği işletmeler. Buradaki sorun genellikle kimsenin hata yapması değil, tanımların hiçbir yerde yazılı olmamasıdır. Ambar kurulurken bu tanımlar tek tek konuşulur, departmanlar mutabık kalır ve tanım kayda geçer. Projenin ilk somut kazancı da çoğu zaman yazılımdan önce bu mutabakat olur.
ERP, üretim takip, e-ticaret, pazaryeri ve hâlâ elde tutulan Excel dosyaları aynı anda kullanılıyorsa tek bir soruyu yanıtlamak için birkaç ekran açmak ve sonra bunları elle birleştirmek gerekir. Bu kaynakların ortak bir modelde buluşması, pano tasarlamadan önce çözülmesi gereken bir altyapı işidir ve kopyala-yapıştır ile sürdürülemez.
Ay sonu raporu çalıştığında ERP'nin yavaşladığı, kullanıcıların terminal başında ekran beklediği tesisler. Bu firmalarda ambar, raporlama yükünü işlem sisteminden ayırır: ERP yalnızca kendi işini yapar, ağır sorgular ayrı bir depoda çalışır. Böylece hem saha rahatlar hem de rapor kapsamı, kullanıcı deneyimini bozma korkusu olmadan genişletilebilir.
Kaynak sistemin eski değerin üzerine yazdığı, dolayısıyla geçen yılın rakamının bugün başka çıktığı yapılar. Yıl karşılaştırması, sezon analizi, bütçe ile gerçekleşen farkı veya müşteri bazlı trend takibi yapmak isteyen her firma bir noktada tarihsel saklama ihtiyacına çarpar. Bu ihtiyaç fark edildiğinde geçmiş çoktan kaybolmuş olur; erken kurmak tek çözümdür.
| Yetenek | Ne sağlar |
|---|---|
| Kaynak envanteri ve veri çekme (ETL / ELT) | ERP, üretim takip, e-ticaret, muhasebe, dosya ve e-posta ekleri dahil hangi verinin nereden geldiği çıkarılır. Çekim mümkün olduğunca değişen kayıt bazında, yani artımlı yapılır ve okuma yükü işlem sistemini yormayacak saatlere alınır. API'si olmayan kaynaklarda salt okunur kopya, veritabanı görünümü veya dosya aktarımı kullanılır. Her kaynak için yükleme sıklığı ayrı belirlenir; hepsini aynı takvime bağlamak gereksiz yük üretir. |
| Katmanlı modelleme: ham, işlenmiş, sunum | Ham katmanda veri kaynaktaki hâliyle, hiç yorumlanmadan saklanır; bir hata çıktığında geriye dönülebilecek tek yer burasıdır. İşlenmiş katmanda alanlar temizlenir, birimler ve kod listeleri ortaklaştırılır, iş kuralları uygulanır. Sunum katmanında ise olgu ve boyut tabloları, yani yıldız şema kurulur; raporlar yalnızca bu katmanı görür. Böylece alttaki yapı değiştiğinde panolar kırılmaz, yalnızca ara katman güncellenir. |
| Tarihsel saklama ve değişim izleme | Kaynakta üzerine yazılan bilgiler ambarda geçmişiyle tutulur. Yavaş değişen boyut (SCD) yöntemiyle bir müşterinin eski bölgesi, bir ürünün eski fiyat grubu ve bir tedarikçinin eski unvanı kayıtta kalır; geçmiş dönem raporları o günkü hâliyle yeniden üretilebilir. Gerektiğinde ay veya dönem sonu anlık görüntüleri alınır. Bu sayede kapanmış bir dönemin raporu, aradan geçen düzeltmelerden etkilenmeden aynı sonucu verir. |
| Veri sözlüğü ve metrik tanımları | Ciro, fire, açık sipariş, duruş süresi gibi her metriğin tanımı, hesaplama kuralı, hangi tablodan geldiği ve kurum içindeki sahibi tek bir sözlükte yazılır. Yeni bir rapor yazan kişi bu tanımı yeniden icat etmez, hazır bulur. Bu sözlük teknik bir belge değildir; departmanların üzerinde anlaştığı ortak dildir. Uygulamada projenin en kalıcı çıktısı da çoğu zaman koddan çok bu sözlük olur. |
| Veri kalitesi kontrolleri | Her yüklemede otomatik testler çalışır: zorunlu alan boş mu, anahtar mükerrer mi, satır sayısı beklenen aralığın dışında mı, bağlı olduğu kayıt bulunamıyor mu, tutarlar beklenmedik biçimde negatif mi. Test düştüğünde sunum katmanı eski hâliyle kalır ve ilgili kişiye uyarı gider; bozuk veri sessizce panoya akmaz. Yanlış rapor üretmektense bir sabah eski veriyle çalışmak her zaman daha az zararlıdır. |
| Yükleme izleme, yeniden çalıştırma ve veri soyağacı | Hangi yüklemenin ne zaman çalıştığı, ne kadar sürdüğü ve kaç satır işlediği izlenir. Yükleme yarıda kesildiğinde aynı iş tekrar çalıştırıldığında veri çiftlenmez; akışlar baştan yeniden çalıştırılabilir biçimde kurulur. Soyağacı (lineage) sayesinde bir panodaki sayının hangi tablodan, o tablonun hangi kaynaktan geldiği izlenir. Bu rakam nereden geliyor sorusu böylece günler değil dakikalar içinde yanıtlanır. |
| Erişim, yetki ve kişisel veri | Ambara kimin hangi katmandan eriştiği tanımlanır; ham katman genellikle yalnızca teknik ekibe açık kalır, iş birimleri sunum katmanını görür. Kişisel veri içeren alanlar gerektiğinde maskelenir veya sunum katmanına hiç taşınmaz. Saklama süreleri ve silme kuralları sonradan eklenen bir madde değil, modelin baştan yazılan parçası olur. Böylece KVKK tarafındaki yükümlülükler ambar büyüdükten sonra sökülmesi gereken bir soruna dönüşmez. |
İşe tablodan değil sorudan başlarız: hangi karar için hangi rakam gerekiyor, bugün nereden alınıyor ve neden tutmuyor. Kaynak sistemler, erişim yöntemleri, veri hacmi ve kalite riskleri çıkarılır. İlk sürümde kapsam dışı bırakılacak alanlar da açıkça yazılır. Kapsamı dar tutmak, ilk güvenilir raporu almanın en hızlı ve en ucuz yoludur.
Kaynaklara salt okunur bağlantı kurulur, artımlı çekim ve yükleme takvimi oturtulur. Bu aşamada henüz rapor üretilmez; hedef verinin eksiksiz, tekrarlanabilir ve işlem sistemini yormadan gelmesidir. Kaynak sayısına göre bu adım çoğu projede birkaç hafta sürer. Aceleye getirildiğinde sonraki her aşama, nedeni bilinmeyen veri farklarıyla uğraşmakla geçer.
İşlenmiş ve sunum katmanları kurulur, olgu ve boyut tabloları tasarlanır, ortak boyutlar tüm konular için tek biçime getirilir. Metrik tanımları departmanlarla tek tek mutabık kalınarak veri sözlüğüne yazılır. Anlaşmazlık çıkan tanımlar kayda geçer ve kapatılmadan devam edilmez; bu tartışmayı ertelemek, sonradan kimsenin güvenmediği bir pano üretmek demektir.
Kalite testleri devreye alınır ve uyarılar bağlanır. Yeni ambar bir süre mevcut raporlarla paralel çalıştırılır, çıkan farklar tek tek incelenir ve nedeni yazılır. Fark bulunması olağandır; çoğu zaman eski raporun hatası bu aşamada ortaya çıkar. Doğrulama tamamlanmadan eski raporlar kapatılmaz ve ambar tek kaynak ilan edilmez.
Yükleme takvimi, uyarılar ve erişim yetkileri açılır. Model, veri sözlüğü ve yükleme akışı belgelenir. Ekibinize yeni bir kaynağın nasıl ekleneceği, bir yüklemenin nasıl yeniden çalıştırılacağı ve bir kalite testi düştüğünde ne yapılacağı yazılı olarak devredilir. Sonrasında bakım, izleme ve yeni konu alanlarıyla genişletme desteği sürer.
İki sayfa üst üste değil, alt alta durur. BI ve raporlama tarafı panoları, KPI ekranlarını, rol bazlı raporları ve otomatik dağıtımı anlatır; yani sonucu gösterir. Bu sayfa o panoların beslendiği katmanı anlatır: verinin nereden çekildiği, nasıl modellendiği, geçmişinin nasıl tutulduğu ve kalitesinin nasıl denetlendiği. Küçük ölçekte ikisi tek projede birlikte kurulur ve ayrı ayrı konuşmaya gerek kalmaz. Kaynak sayısı, geçmiş ihtiyacı ve rapor sayısı arttığında ise ambar kendi başına bir iş, kendi bakımı olan bir sistem haline gelir.
Veri gölü (data lake) ham dosyaları olduğu gibi, şeması sonradan belirlenmek üzere biriktirir; görüntü, log ve sensör akışı gibi yapısal olmayan veride güçlüdür. Veri ambarı ise modellenmiş, tanımı sabit, raporlamaya hazır veriyi tutar ve iş birimlerinin doğrudan kullanabileceği tek yerdir. Üretim ve ticaret raporlaması için çoğu işletmenin ihtiyacı ambardır. Gölü, sensör ve görüntü verisi gibi hacimli kaynaklar devreye girdiğinde ambarın önüne bir toplanma alanı olarak ekleriz; ikisi rakip değil, arka arkaya duran iki katmandır.
Hayır. Ambar kirli veriyi görünür kılar, düzeltmez. Aynı müşteri kaynakta üç kez açılmışsa ambarda da üç kayıt olur; ürün kodları standart değilse rapor da standart olmaz. Kalite testleri bu sorunları ilk kez sayıyla önünüze koyar, yani bir teşhis üretir; düzeltme ise kaynak sistemde veya ana veri yönetimi (MDM) katmanında yapılır. Bunu baştan söylüyoruz, çünkü ambar kuralım da veri düzelsin beklentisiyle başlayan projeler istisnasız hayal kırıklığıyla biter.
Her firmaya gerekmez. Tek bir ERP kullanıyorsanız, birkaç standart rapora bakıyorsanız ve geçmişi karşılaştırma ihtiyacınız sınırlıysa ayrı bir ambar kurmak çözdüğünden fazla bakım yükü getirir; bu durumda doğrudan raporlama katmanı yeterlidir ve daha ucuzdur. Ambar; kaynak sayısı arttığında, aynı metrik farklı yerlerde farklı hesaplandığında, geçmişin değişmeden durması gerektiğinde veya raporlar işlem sistemini yorduğunda anlamlı olur. Keşifte gerekli görmezsek bunu açıkça söyler, daha küçük bir çözüm öneririz.
Amaç tam tersidir: ağır raporları işlem sisteminden çıkarmak ERP'yi rahatlatır. Çekim salt okunur bağlantı, kopya veya değişiklik veri yakalama (CDC) ile yapılır ve mümkün olduğunca düşük yoğunluklu saatlere alınır; yükleme penceresi sizin vardiya düzeninize göre belirlenir. Tazelik ise metrik metrik kararlaştırılır: sevkiyat panosu saatlik, mali raporlar gecelik, bazı analizler haftalık olabilir. Her şeyi anlık tutmak teknik olarak mümkündür ama çoğu metrikte karşılığı olmayan bir maliyet üretir.
Kaynaklardan artımlı çalışan yükleme akışları; ham, işlenmiş ve sunum katmanlarından oluşan modellenmiş bir ambar; geçmişi tutan boyut tabloları; metrik tanımlarının yazılı olduğu veri sözlüğü; her yüklemede çalışan kalite testleri ve uyarılar; yükleme izleme ekranı ile veri soyağacı; kaynak ekleme ve yeniden çalıştırma yordamlarını anlatan dokümantasyon. Kaynak kod, veri modeli, dokümantasyon ve ambardaki verinin tamamı size aittir; veri kendi altyapınızda veya seçtiğiniz bulutta durur.
30 dakikalık keşif görüşmesinde ihtiyacınızı dinler, özele mi yoksa hazır çözüme mi ihtiyacınız olduğunu dürüstçe söyleriz.
Aynı müşterinin üç kez açıldığı, aynı malzemenin iki kodla durduğu kayıt düzenini onarırız. Eşleştirme kuralları, benzerlik skoru ve inceleme kuyruğuyla mükerrer kayıtlar tekilleştirilir, altın kayıt üretilir ve kaynak sistemlere geri dağıtılır; yeni kayıt açılırken benzer kayıt uyarısı devreye girer.
Detay →Tanı amaçlı görüntüleme yazılımı üretmiyoruz; mevcut PACS'ınız yerinde kalır. Biz cihaz worklist'i, hasta kaydı, istem, rapor ve paylaşım arasındaki boşluğu kapatan katmanı kurarız: görüntü doğru hastaya bağlanır, bekleyen istem görünür olur, arşivin saklama ve yedekleme durumu denetlenebilir hale gelir.
Detay →Başvuru, kayıt, şube yerleştirme, ders programı, yoklama, not, karne, veli iletişimi ve taksit takibini tek kayıt üzerinde birleştiren öğrenci bilgi sistemi kuruyoruz. Kurumun kendi takvimine ve kendi ücret politikasına göre kurgulanır; hazır bir paketin kalıbına girmeniz gerekmez. Kaynak kod ve veri kuruma aittir.
Detay →Numunenin kabul edildiği andan analiz sertifikasına kadar tüm adımları tek kayıt üzerinde yürüten laboratuvar bilgi yönetim sistemi kuruyoruz: barkodlu numune takibi, metot kütüphanesi, cihaz bağlantısı, spesifikasyon kontrolü, kademeli onay ve denetime hazır kayıt düzeni.
Detay →Teklif, proje, zaman kaydı, hakediş ve fatura zincirini tek kayıt üzerinde birleştiririz. Ajans, danışmanlık, mühendislik ve yazılım firmalarında kimin hangi işe ne kadar zaman verdiği, kaynak doluluk oranı ve proje kârlılığı iş bittikten sonra değil, iş sürerken görünür hale gelir.
Detay →Hastane bilgi yönetim sisteminizin yerine geçmeyiz; yanında çalışan bir işletme katmanı kurarız. Randevu ve kaynak doluluğu, tedavi planı takibi, hatırlatma, sarf ve implant stoğu, sağlık turizminde hasta yolculuğu ve yönetim panosu bu katmanda toplanır. Kaynak kod ve veri sizde kalır.
Detay →
