SAP Business One’da MS SQL’den HANA’ya Geçiş Rehberi

SAP Business One’da MS SQL’den SAP HANA’ya geçişin özü şudur: veritabanı platformu değişir, iş verileriniz ve alışık olduğunuz ekranlar korunur; karşılığında in-memory performans, yalnızca HANA’da sunulan gömülü analitik araçları ve SAP’nin geleceğe dönük yol haritasıyla hizalanma kazanılır. Geçiş, SAP’nin araçlarıyla desteklenen olgun bir süreçtir — ama add-on’ların ve özel SQL sorgularının uyarlanması gerektiği için “kur ve unut” işi değildir. Bu yazıda geçişin gerekçelerini, adımlarını ve sahada en çok sorun çıkaran noktaları anlatıyoruz.

Neden HANA: dört gerekçe

HANA geçişini konuşan şirketler genellikle tek bir şikayetle geliyor: “Sistem yavaşladı.” Bu geçerli bir tetikleyici, ama kararın arkasında dört ayrı gerekçe var ve hangisinin sizin için ağır bastığı, geçişin zamanlamasını ve beklentiyi belirler.

In-memory performans. HANA veriyi diskten okumak yerine bellekte, kolon bazlı tutar. Bunun günlük karşılığı, veri hacmi büyüdükçe hissedilir: yıl sonu raporları, çok satırlı yaşlandırma ve stok değerleme koşuları, MRP hesapları gibi ağır işlemler belirgin hızlanır. Küçük veriyle çalışan bir şirkette fark sınırlı kalabilir; asıl kazanım, büyüyen veriyle yavaşlamayan bir sistemdir.

Gömülü analitik. SQL Server üzerinde rapor ihtiyacı genellikle Crystal Reports ve harici araçlarla karşılanır. HANA sürümü ise analitiği ürünün içine gömer: Pervasive Analytics ile kod yazmadan KPI ve dashboard tasarlanır, Interactive Analysis ile kullanıcılar Excel pivot rahatlığında canlı veri üzerinde çalışır. Rapor talebi “BT’ye açılan iş emri” olmaktan çıkıp kullanıcının kendi yapabildiği bir işe döner.

Yalnızca HANA’da sunulan işlevler. Enterprise Search (tüm sistemde serbest metin arama), gelişmiş nakit akışı öngörüsü, gelişmiş ATP (sipariş vaadi) kontrolü gibi bir dizi özellik SQL sürümünde yoktur. Bu liste sürümden sürüme HANA lehine genişliyor.

Yol haritası. SAP’nin ürün yatırımı ve yeni özellik geliştirmesi ağırlıkla HANA hattında ilerliyor. Bu, SQL kurulumlarının yarın duracağı anlamına gelmez; ama uzun vadeli planı olan bir şirketin yeni yatırımı platformun gittiği yöne yapması daha sağlıklıdır. SAP Business One tarafında versiyon stratejinizi konuşurken bu ekseni mutlaka masaya koyuyoruz.

SQL ve HANA üzerinde SAP Business One: özet karşılaştırma

Boyut	MS SQL üzerinde B1	HANA üzerinde B1
Veritabanı mimarisi	Disk tabanlı, satır bazlı	In-memory, kolon bazlı
Ağır rapor/MRP performansı	Veri büyüdükçe yavaşlar	Büyük veride belirgin avantaj
Gömülü analitik	Yok; harici araç gerekir	Pervasive Analytics, Interactive Analysis
Enterprise Search	Yok	Var
Özel sorgu dili	T-SQL	HANA SQL / SQLScript — uyarlama gerekir
İşletim sistemi	Windows Server	SUSE Linux (HANA sunucusu)
Yol haritası	Bakım odaklı	Yeni özelliklerin ana hattı

Tablodaki son iki satır, geçişin “bedava” olmadığını da gösteriyor: HANA bir Linux sunucusunda koşar ve mevcut T-SQL varlıklarınız otomatik taşınmaz. Kazanımlar gerçek, ama bir proje disipliniyle alınıyor.

SQL’de kalmak ne zaman makul

Dürüst olalım: her kurulumun bugün HANA’ya koşması gerekmiyor. Şu üç durumda “bekle ve planla” demek, “hemen geç” demekten daha doğru danışmanlıktır:

• Veri hacmi küçük ve performans şikayeti yoksa. In-memory mimarinin farkı büyük veride açılır; bugün akıcı çalışan küçük bir kurulumda geçişin kısa vadeli getirisi sınırlıdır. Karar, büyüme projeksiyonuna göre verilmelidir.
• Kritik bir add-on’un HANA sürümü henüz yoksa. İş akışınızın ortasındaki bir add-on HANA’da çalışmıyorsa geçiş zaten mümkün değildir; doğru hamle üreticiden yol haritası almak ve geçişi ona göre takvimlemektir.
• Donanım yenileme döngüsünün ortasındaysanız. Yeni alınmış SQL sunucusunun ömrünü tüketmeden HANA donanımına yatırım, finansal olarak zor savunulur. Geçişi bir sonraki donanım yenilemesiyle birleştirmek, aynı projede iki maliyeti tek pencerede toplar.

Bu üç durumun hiçbiri geçerli değilse — veri büyüyor, add-on’lar hazır, donanım ömrünü doldurmak üzereyse — beklemenin kendisi maliyet üretmeye başlar: yavaşlayan kapanışlar, alınamayan analitik ve her yıl biraz daha büyüyen, dolayısıyla taşınması biraz daha zorlaşan bir veritabanı.

Geçiş adımları

1. Mevcut durum ve uyumluluk analizi

İlk iş envanter çıkarmaktır: hangi B1 sürümündesiniz, hangi add-on’lar kurulu, kaç özel sorgu, kaç Crystal raporu, kaç UDF/UDT var. Her add-on’un HANA sürümünün olup olmadığı üreticisinden teyit edilir — sahada geçişi geciktiren bir numaralı madde, HANA desteği olmayan ya da ayrı lisans isteyen üçüncü parti add-on’lardır. Eski bir B1 sürümündeyseniz geçiş genellikle sürüm yükseltmeyle birlikte planlanır; bu, projenin kapsamını ve test yükünü değiştirir, baştan bilinmelidir.

2. Donanım ve sizing

HANA’nın bellek gereksinimi, veritabanı boyutunuza ve büyüme projeksiyonunuza göre hesaplanır; SAP’nin sizing kılavuzları bu hesabın çerçevesini verir. Burada iki yol var: kendi sunucunuz (on-premise) ya da barındırılan/bulut model. Kendi sunucu senaryosunda sertifikalı donanım ve SUSE Linux yönetimi gündeme gelir; BT ekibi Windows ağırlıklıysa bu yeni bir yetkinlik kalemidir ve işletme planına yazılmalıdır.

3. Test ortamında migrasyon provası

Canlı geçişten önce mevcut veritabanının bir kopyası, test ortamında SAP’nin migrasyon araçlarıyla HANA’ya taşınır. Bu prova üç şey verir: gerçek kesinti süresinin ölçümü, migrasyon sırasında çıkacak veri ve uyumluluk hatalarının listesi, ve kullanıcıların yeni ortamı canlıdan önce görebileceği bir çalışma alanı. Provasız doğrudan canlı geçiş, sahada gördüğümüz en gereksiz risklerden biri — kesinti penceresinin ortasında sürprizle karşılaşmanın maliyeti, bir test turunun maliyetiyle kıyaslanamaz.

4. Add-on ve özel geliştirmelerin uyarlanması

Projenin asıl emek yiyen fazı budur. T-SQL ile yazılmış kullanıcı sorguları, onaylı prosedürlerdeki sorgu koşulları, özel raporlar ve entegrasyon katmanındaki SQL’ler HANA diyalektine uyarlanır. İki tuzağa özellikle dikkat: HANA büyük/küçük harfe duyarlıdır — SQL Server’da yıllarca sorunsuz çalışmış sorgular, tırnak içine alınmış küçük harfli tablo ve alan adlarında ya da metin karşılaştırmalarında HANA’da hata verebilir — ve T-SQL’e özgü fonksiyon ve söz dizimleri birebir karşılık gelmez. Sorgu envanteri ne kadar büyükse bu faz o kadar uzar; bu yüzden 1. adımdaki envanter çalışması yüzeysel geçilmemelidir.

5. Kesinti penceresi ve canlı geçiş

Prova ölçümlerine dayanarak gerçek kesinti planlanır: hangi gece ya da hafta sonu, kaç saat, kim hangi adımı yürütüyor, hangi koşulda geri dönülüyor. Geri dönüş planı pazarlık konusu değildir — eski SQL ortamı, yeni ortam doğrulanana kadar el değmeden bekletilir. Kesinti penceresine veri taşıma dışında iş sıkıştırmayın; sürüm yükseltme provada birleştirilmediyse aynı geceye eklenmemelidir.

Geçiş gecesinin iskeleti projeden projeye pek değişmez; yazılı bir koşu planında en azından şunlar durmalıdır:

• Kullanıcı çıkışı ve entegrasyonların (e-fatura, e-ticaret, banka) durdurulması
• Son tam yedek ve yedeğin geri dönülebilirlik testi
• Migrasyon koşusu ve araç loglarının anlık takibi
• Teknik doğrulama: kayıt sayıları, bakiyeler, açık belgeler
• Anahtar kullanıcılarla hızlı işlevsel tur (sipariş → irsaliye → fatura)
• Entegrasyonların yeni ortama yönlendirilip tek tek test edilmesi
• “Devam / geri dön” kararının kimin vereceğinin ve saat sınırının baştan yazılması

6. Doğrulama ve devir

Geçiş sonrası doğrulama iki katmanlıdır. Teknik katman: kayıt sayıları, stok ve cari bakiyeleri, açık belge listeleri eski ve yeni ortamda karşılaştırılır. İş katmanı: anahtar kullanıcılar kendi süreçlerini — sipariş girişi, irsaliye, fatura, MRP koşusu, dönem raporları — yeni ortamda uçtan uca koşar. İlk haftalarda performans ve hata izlemesi için yakın bir teknik destek düzeni kurulur; sorunların çoğu ilk gerçek ay kapanışında görünür, bu yüzden destek penceresini ilk kapanışı kapsayacak şekilde planlamak gerekir.

Riskler ve dikkat edilecekler

• Add-on kör noktası. HANA sürümü olmayan bir add-on, geçişi tek başına bloke edebilir. Envanteri projenin en başında çıkarın, üreticilerden yazılı teyit alın.
• Sorgu envanterini küçümsemek. Yıllar içinde birikmiş kullanıcı sorguları çoğu şirkette sanılandan kalabalıktır. Kullanılmayanları taşımayın; bu, temizlik için de bir fırsattır.
• Sizing’i dar tutmak. Bellek hesabını bugünün verisine göre yapmak, birkaç yıl içinde ikinci bir donanım yatırımı demektir. Büyüme payını baştan koyun.
• Linux işletim yükünü unutmak. HANA sunucusunun yamaları, yedeği ve izlemesi bir işletim sorumluluğudur; içeride yetkinlik yoksa barındırılan model ya da dış destek baştan planlanmalıdır.
• Eğitimi atlamak. Kullanıcı ekranları büyük ölçüde aynı kalır, ama analitik araçlar yenidir. Pervasive Analytics ve Interactive Analysis eğitimsiz kalırsa, geçişin en görünür kazanımı kullanılmayan bir özellik olarak kalır.

Geçiş sonrası ilk ay: neyi izliyoruz

Canlı geçişin başarılı olması, projenin bittiği anlamına gelmez; sorunların önemli bölümü ilk gerçek iş yükünde görünür. İlk ayda yakından izlediğimiz başlıklar şunlar:

• İlk ay kapanışı. Dönem sonu raporları, yaşlandırma ve stok değerleme koşuları eski ortamın sonuçlarıyla karşılaştırılır; sapma varsa kaynağı kapanıştan önce bulunmalıdır.
• Uyarlanmış sorguların davranışı. Test ortamında doğru sonuç veren bir sorgu, canlı veri hacminde performans sorunu çıkarabilir; yavaşlayan sorgular listelenip elden geçirilir.
• Entegrasyon akışları. E-fatura, banka ve e-ticaret hatlarında kuyruk birikmesi ya da sessiz hata olup olmadığı günlük kontrol edilir — entegrasyon hataları kullanıcı şikayetinden önce logda görünür.
• HANA sunucu sağlığı. Bellek kullanımı, yedek koşuları ve log alanı ilk aydan itibaren düzenli izlenmeye alınır; izleme düzeni kurulmadan devir yapılmaz.

Geçişin “yapılmalı mı, ne zaman yapılmalı” tarafı ise teknik değil stratejik bir soru: veri hacminiz, büyüme planınız, add-on bağımlılıklarınız ve donanım yenileme takviminiz birlikte değerlendirilmelidir. Bu değerlendirmeyi ERP danışmanlığı çerçevesinde, envanter ve sizing çalışmasıyla birlikte yapıyoruz; karar ancak bu tablo netken sağlıklı verilir.

Sık sorulan sorular

SQL’den HANA’ya geçişte verilerim kaybolur mu?

Hayır; geçiş, mevcut veritabanınızın SAP’nin migrasyon araçlarıyla HANA’ya taşınmasıdır ve tüm iş verileriniz korunur. Doğru kurgulanmış bir projede önce test ortamında prova yapılır, canlı geçiş sonrası bakiyeler ve kayıt sayıları eski ortamla karşılaştırılarak doğrulanır; eski SQL ortamı da doğrulama bitene kadar geri dönüş imkanı olarak saklanır.

HANA geçişi ne kadar sürer?

Veritabanının kendisinin taşınması genellikle bir kesinti penceresine sığar; projenin asıl süresini add-on uyumluluğu, özel sorguların uyarlanması ve test turları belirler. Az özelleştirilmiş bir sistemde süreç kısa sürerken, yoğun add-on ve sorgu envanteri olan bir kurulumda uyarlama fazı belirgin uzar — bu yüzden süre tahmini ancak envanter çalışmasından sonra verilebilir.

SAP Business One HANA için ayrı veritabanı lisansı gerekir mi?

SAP Business One’ın HANA sürümü, HANA veritabanını B1’e özel runtime lisansıyla kullanır; SQL Server lisansına benzer şekilde bu kalem teklifte yer alır, ayrıca kurumsal bir HANA platform lisansı satın almanız gerekmez. Mevcut kullanıcı lisanslarınızın HANA’ya nasıl aktarılacağı ise sözleşmenize bağlıdır ve partner teklifinde netleştirilmelidir.

Mevcut add-on’larım ve özel raporlarım HANA’da çalışır mı?

Add-on’lar ancak üreticisi HANA sürümü yayınladıysa çalışır; bu yüzden geçiş projesinin ilk adımı add-on envanteri ve üretici teyididir. T-SQL ile yazılmış kullanıcı sorguları ve raporlar otomatik dönüşmez, HANA söz dizimine uyarlanmaları gerekir — büyük/küçük harf duyarlılığı ve fonksiyon farklılıkları en sık düzeltme gerektiren iki noktadır.