SAP Business One HANA Nedir? Avantajları ve SQL Farkı

SAP HANA, verinin diskte değil bellekte (in-memory) ve sütun bazlı tutulduğu, SAP'nin kendi geliştirdiği veritabanı platformudur; SAP Business One'ın HANA sürümü bu platform üzerinde çalışır. B1 kullanıcısı için pratik anlamı şudur: milyonlarca satırlık hareket verisinde raporlar ve analizler, satır bazlı klasik veritabanına göre belirgin biçimde hızlı döner ve analitik özellikler (gömülü arama, interaktif analiz, dashboard altyapısı) ürünün doğal parçası haline gelir. SQL Server sürümü aynı iş mantığını çalıştırır; fark, veritabanı motorunun yeteneklerinde ve SAP'nin yeni yatırımlarını hangi tarafa yaptığındadır.

Bu yazıda HANA'yı pazarlama diliyle değil, SAP Business One projelerinde iki sürümü de devreye almış bir ekibin gözünden anlatıyoruz: ne gerçekten değişiyor, ne değişmiyor, geçiş kararı neye göre verilmeli.

In-memory ve sütun bazlı mimari ne demek

Klasik veritabanları veriyi diskte, satır satır tutar: bir faturanın tüm alanları yan yana durur. Bu, tekil belge okuma-yazma için idealdir. HANA ise veriyi ağırlıklı olarak bellekte ve sütun bazlı tutar: tüm faturaların "tutar" sütunu bir arada durur. Bu da toplama, gruplama, filtreleme gibi analitik işlemleri — yani rapor sorgularının doğasını — çok hızlandırır.

B1 özelinde bunun görünür karşılıkları:

• Yıl sonu geldiğinde yavaşlamaya başlayan yaşlandırma, stok değerleme, kârlılık raporları büyük veri hacminde de akıcı kalır.
• "Bu raporu gece çalıştıralım" alışkanlığı büyük ölçüde ortadan kalkar; analiz, toplantı sırasında canlı yapılabilir hale gelir.
• Rapor için ayrı bir veri ambarına kopyalama ihtiyacı gecikir; veri tek yerde, günceldir.

Dürüst olalım: tekil belge işlemlerinde — sipariş girişi, fatura kaydetme — HANA ile SQL arasında kullanıcı hissedeceği dramatik bir fark yoktur. HANA'nın farkı okuma-analiz yükü arttıkça açılır. On kullanıcılı, raporlama ihtiyacı sınırlı bir şirkete "HANA'sız olmaz" demek satış ağzıdır; veri hacmi ve analiz iştahı büyüyen şirkette ise fark her çeyrek daha görünür olur.

HANA sürümünün B1'e kattığı özellikler

HANA yalnızca hızlı veritabanı değil; B1'in HANA sürümüne özel yetenekler getirir:

Yetenek	Ne sağlar
Enterprise Search	Tüm belgelerde ve ana verilerde Google benzeri serbest metin arama
Interaktif analiz	Excel pivot mantığında, canlı veriyle çalışan analiz görünümleri
Pervasive Analytics	Kullanıcı ekranlarına gömülü KPI ve dashboard tasarımı
Gelişmiş MRP ve tahminleme	Daha zengin planlama senaryoları
Service Layer performansı	Yoğun entegrasyon yükünde daha rahat ölçekleme

Sahada en çok karşılık bulan ikisi Enterprise Search ve gömülü analitik. Arama, "şu tutarda bir fatura vardı ama numarasını bilmiyorum" tipindeki günlük dertleri bitiriyor; gömülü KPI'lar ise yöneticinin rapor istemek yerine ekranında hazır görmesini sağlıyor. Bunlar kâğıt üstünde küçük, günlük kullanımda büyük farklar.

SQL Server sürümünden farklar: karar tablosu

Kriter	B1 HANA	B1 SQL Server
Veritabanı motoru	SAP HANA (in-memory, sütun bazlı)	Microsoft SQL Server (satır bazlı)
Analitik performans	Büyük veri hacminde belirgin üstün	Hacim büyüdükçe bakım/indeks çalışması ister
HANA'ya özel özellikler	Var (arama, analitik, gelişmiş MRP)	Yok
Donanım gereksinimi	Daha yüksek bellek, sertifikalı sunucu	Daha mütevazı, tanıdık altyapı
BT ekibi aşinalığı	Türkiye'de daha az yaygın uzmanlık	SQL Server bilgisi yaygın
SAP yol haritası	Yeni yatırımların odağı	Bakımda, yenilik odağı değil

Karar pratikte üç soruya iner. Birincisi veri ve analiz iştahı: hareket hacminiz büyüyor, raporlama talebi artıyorsa HANA'nın değeri gerçek. İkincisi altyapı: HANA sertifikalı sunucu yatırımı ya da bulut barındırma gerektirir; bu kalemi toplam maliyet hesabına baştan koymak gerekir. Üçüncüsü ufuk: SAP'nin yeniliği HANA tarafına yazdığı bir dünyada yeni kuruluma SQL ile başlamak, birkaç yıl içinde bir geçiş projesini bugünden takvime yazmaktır.

Yeni kurulumda ve geçişte önerdiğimiz yaklaşım

Yeni kurulumda varsayılan önerimiz HANA — bulut aboneliği bu kararı kolaylaştırdı, çünkü sunucu yatırımı yerine barındırmayı aboneliğin içinde almak mümkün. SQL ile başlamayı yalnızca mevcut güçlü bir SQL Server altyapısı ve ekibi olan, analitik ihtiyacı sınırlı şirketlerde konuşuruz.

Mevcut SQL kurulumundan geçişte ise acele önermeyiz. Geçiş teknik olarak olgun bir süreçtir ama bir proje disiplini ister: add-on'ların ve özelleştirmelerin HANA uyumluluğu tek tek doğrulanır — özellikle doğrudan SQL sorgusu içeren raporlar ve eski add-on'lar bu noktada iş çıkarır —, veritabanı taşınır, performans ve yetki testleri koşulur. Projelerimizde bu geçişi genellikle bir sürüm yükseltmeyle birleştiririz; iki kesintiyi tek pencerede toplamak operasyona daha az dokunur.

Geçiş kararının zamanlaması için şu işaretlere bakarız: ay sonu raporları saatlere uzamaya başladıysa, kullanıcılar analiz için veriyi Excel'e kaçırıyorsa, entegrasyon yükü Service Layer'ı zorluyorsa — HANA konuşmanın vakti gelmiş demektir. Bu işaretler yokken geçiş, fayda üretmeyen bir masraf olabilir; danışmanlık ekibimiz bu değerlendirmeyi mevcut sisteminizin gerçek metrikleri üzerinden yapar.

HANA hakkında yanlış bilinenler

Karar toplantılarında düzelttiğimiz dört yaygın yanılgı:

• "HANA'ya geçince her şey hızlanır." Hayır; hızlanan ağırlıkla okuma/analiz yüküdür. Tekil belge girişindeki hissiyat büyük ölçüde aynı kalır. Yavaşlığın kaynağı kötü yazılmış özel bir sorgu ya da ağ ise, motor değişikliği o sorunu taşımaya devam eder.
• "HANA ayrı bir ürün, B1'i yeniden mi alıyoruz?" Hayır; iş mantığı, ekranlar ve verinizin anlamı aynıdır. Değişen veritabanı motoru ve onunla gelen analitik katmandır; kullanıcı eğitimi yeniden yapılmaz, fark özelliklerine kısa bir tanıtım yeter.
• "SQL bilgimiz çöpe gider." Gitmez; HANA da SQL konuşur. Değişen, sorgu diyalektindeki farklar ve mevcut özel raporların gözden geçirilmesi ihtiyacıdır — bu, geçiş projesinin bilinen ve planlanabilir bir kalemidir.
• "Bellek pahalı, HANA bu yüzden lüks." Bellek fiyatları bu argümanın yazıldığı yıllardan beri geriledi; bulut barındırmayla birlikte HANA'nın giriş eşiği, KOBİ ölçeğinin gerçekçi bandına indi. Lüks olup olmadığını genelleme değil, sizin analiz ihtiyacınız belirler.

Geçiş projesinin adımları

Mevcut SQL kurulumundan HANA'ya geçişi şu iskeletle planlarız:

1. Envanter: Add-on'lar, özel raporlar, doğrudan SQL sorguları ve entegrasyonlar listelenir; her birinin HANA uyumluluğu işaretlenir.
2. Altyapı kararı: Sertifikalı sunucu mu, bulut barındırma mı? Boyutlandırma, veri hacmi ve büyüme projeksiyonuyla yapılır.
3. Test göçü: Veritabanı test ortamına taşınır; uyumsuz çıkan rapor ve uyarlamalar burada düzeltilir.
4. Doğrulama: Anahtar kullanıcılar kendi süreçlerini test ortamında uçtan uca koşar; mali tablolar iki ortamda karşılaştırılır.
5. Canlı geçiş penceresi: Genellikle hafta sonuna planlanır; geri dönüş (rollback) planı yazılı olmadan pencere açılmaz.
6. Yakın izleme: İlk haftalarda performans ve entegrasyon davranışı izlenir; HANA'ya özgü özellikler (arama, analitik görünümler) bu fazda kademeli açılır.

Bu iskeletin süresi envanterin kirliliğine göre değişir; disiplinli yürütülen geçişte kullanıcının yaşadığı kesinti, tek bir hafta sonu penceresidir.

HANA zamanının geldiğini gösteren işaretler

Mevcut bir SQL kurulumunda şu belirtiler biriktiyse, geçiş konuşmasını ajandaya almanın vakti gelmiştir:

• Ay sonu ve dönem kapanışı raporları saatlere uzuyor, raporlar gece koşusuna taşınıyor
• Kullanıcılar analiz için veriyi düzenli olarak Excel'e çekiyor — sistem raporlarına güven ya da sabır kalmamış
• Yönetim "anlık" sorularına (bugünkü kârlılık, güncel stok değeri) ancak günler sonra cevap alabiliyor
• Entegrasyon ve Service Layer yükü büyüdükçe ekran tarafında yavaşlama hissediliyor
• Veri hacmi her yıl belirgin büyüyor ve arşivleme/küçültme tartışmaları başlamış durumda
• Yeni analitik ihtiyaçlar için ayrı BI aracı ve veri ambarı yatırımı konuşuluyor

Tek bir işaret gerekçe değildir; ama üçü-dördü aynı anda yaşanıyorsa, sorunu SQL tarafında indeks bakımıyla ötelemek yerine yapısal çözümü konuşmak daha ekonomiktir. Tersi de geçerli: bu listeden hiçbiri yaşanmıyorsa, geçişi pazarlama takvimi değil kendi ihtiyaç takviminiz belirlemelidir.

Boyutlandırma ve altyapı notları

HANA tarafında boyutlandırma, "en büyük sunucuyu al" refleksiyle değil veri hacmi ve büyüme projeksiyonuyla yapılır. Dikkat ettiğimiz noktalar: bellek ihtiyacının bugünkü veriye değil üç yıllık projeksiyona göre hesaplanması, test/geliştirme ortamının plana dahil edilmesi ve yedekleme-geri dönüş senaryosunun kurulum gününde test edilmesi. Bulut barındırmada bu kalemlerin çoğu sağlayıcı sorumluluğuna geçer; kendi sunucunuzda ise her biri sizin (veya destek partnerinizin) takvimindedir — bu ayrımın karar tarafını bulut mu on-premise mi rehberinde işledik.

Sık sorulan sorular

HANA sürümü daha mı pahalı?

Toplamda genellikle evet, çünkü denkleme HANA altyapısı (sertifikalı sunucu veya barındırma) girer. Ancak karşılaştırmayı salt lisans etiketiyle değil, analitik ihtiyacın başka araçlarla (ayrı BI, veri ambarı) kapatılma maliyetiyle birlikte yapmak gerekir; HANA bu araçların bir kısmını gereksizleştirir.

Mevcut raporlarımız ve add-on'larımız HANA'da çalışır mı?

Standart ekranlar ve Crystal raporların çoğu sorunsuz taşınır; doğrudan SQL sorgusu içeren raporlar ve eski add-on'lar uyarlama isteyebilir. Geçiş projelerinde ilk işimiz bu envanteri çıkarıp uyumluluk testinden geçirmektir.

HANA için kendi sunucumuzu almak zorunda mıyız?

Hayır; sertifikalı sunucu yatırımı yerine bulut barındırma veya abonelik modeliyle çalışmak mümkün. Nakit akışı ve BT ekibi kapasitesine göre iki model de kurulabilir; ayrıntısını bulut yazımızda ele alıyoruz.

SQL sürümü ortadan kalkacak mı?

Bugün itibarıyla iki sürüm de yaşıyor; ancak SAP'nin yeni özellik yatırımı belirgin biçimde HANA tarafında. Yeni kurulum kararında bunu bir yön işareti olarak okumak gerekir: uzun ömürlü bir yatırım yapıyorsanız akıntıyla aynı yöne yüzmek maliyeti düşürür.

Geçiş sırasında sistem ne kadar süre kapalı kalır?

Disiplinli planlanan geçişte kullanıcı kesintisi tek bir hafta sonu penceresine sığar; asıl takvimi tüketen, kesinti değil öncesindeki envanter ve test fazlarıdır. Geri dönüş planı yazılı olduğu sürece pencere risksizdir — test göçünde doğrulanmamış hiçbir adım canlı pencerede ilk kez denenmez.

HANA ile birlikte hangi raporlama araçları gelir?

Gömülü interaktif analiz, Pervasive Analytics panoları ve Crystal Reports tarafı kurulumla birlikte kullanılabilir; çoğu KOBİ'nin rapor ihtiyacı bu setle karşılanır. Ayrı bir BI aracı ancak çok kaynaklı (B1 dışı verilerle birleşen) analiz ihtiyacında gündeme gelir; o kararı araç merakıyla değil, somut rapor listesiyle veririz.

Değerlendirmeye nereden başlamalıyız?

Mevcut kurulumunuz için en hızlı başlangıç, yukarıdaki işaret listesini kendi sisteminizde puanlamak ve en yavaş üç raporunuzun süresini ölçmektir. Bu iki veriyle yapılan bir değerlendirme görüşmesi, geçişin size ne kazandıracağını genel vaatlerle değil kendi rakamlarınızla konuşmayı mümkün kılar; danışmanlık ekibimiz bu analizi mevcut sistem üzerinde yapar.

Sonuç geçiş lehine çıkmıyorsa bunu da açık söyleriz; motoru değiştirmenin fayda üretmediği bir sistemde geçiş önermek, bizim çalışma ilkelerimize aykırıdır.