Logo Tiger'dan SAP Business One'a Geçiş: Proje Nasıl Yürür?

Logo Tiger'dan SAP Business One'a geçiş, dört ana fazdan oluşan bir projedir: kapsam ve süreç analizi, sistem kurulumu ve uyarlama, veri taşıma ile paralel çalışma dönemi, ve kontrollü canlıya geçiş. Dar kapsamlı bir KOBİ geçişi tipik olarak 2-8 hafta sürer; çok lokasyonlu, entegrasyon yoğun projeler 8-12 aya uzayabilir. Projenin başarısını belirleyen şey yazılımın kendisi değil, geçiş döneminin ne kadar disiplinli yönetildiğidir.

30'dan fazla ERP dönüşümü tamamlamış bir ekip olarak sahada en sık gördüğümüz yanılgı şu: geçiş bir "kurulum işi" gibi planlanıyor. Oysa Tiger'dan SAP Business One'a geçen bir şirket yalnızca yazılım değiştirmiyor; yıllardır alışılmış iş yapış biçimlerini, kod yapılarını ve raporlama alışkanlıklarını da değiştiriyor. Bu yazıda projenin nasıl yürüdüğünü, veri taşımanın inceliklerini ve paralel dönemin neden pazarlık konusu olmaması gerektiğini adım adım anlatıyoruz.

Geçiş kararından önce: neden ve ne zaman

Tiger kullanan bir şirketin geçiş sinyalleri genellikle benzerdir: Excel'de dönen paralel süreçlerin çoğalması, şube veya yurt dışı operasyon eklendiğinde sistemin yetersiz kalması, üretim ve maliyet muhasebesinin gerçek zamanlı izlenememesi, entegrasyonların her seferinde özel geliştirme gerektirmesi. Bu tabloyu SAP Business One vs Logo Tiger karşılaştırmamızda ayrıntılı ele almıştık.

Zamanlama tarafında önerimiz net: geçişi mali yıl başına denk getirmek işi ciddi kolaylaştırır. Yıl ortası geçişte açılış bakiyelerinin yanına dönem içi hareketleri de taşımak gerekir; bu hem veri taşıma yükünü hem mutabakat riskini büyütür. Zorunlu değilse dönem başını bekleyin, aradaki süreyi analiz ve veri temizliğine harcayın.

Faz 1 — Kapsam ve süreç analizi

Projenin en kritik fazı budur ve en çok kısaltılmak istenen fazdır. Analiz aşamasında yaptığımız iş özetle şu: Tiger'daki mevcut akışları (satış, satın alma, stok, finans, varsa üretim) belgelemek, hangi süreçlerin birebir taşınacağına ve hangilerinin SAP Business One'ın standart akışına uyarlanacağına karar vermek.

Burada danışman ağzıyla açık konuşalım: Tiger'daki her alışkanlığı SAP tarafında birebir yeniden yaratmaya çalışmak, projelerin en pahalı hatasıdır. Sahada şunu görüyoruz — "bizde bu ekran şöyleydi" cümlesiyle başlayan her özelleştirme talebi, hem bütçeyi hem sürüm geçişlerindeki bakım yükünü büyütüyor. Doğru soru "eski ekran nasıldı" değil, "bu sürecin çıktısı ne olmalı" sorusudur. Danışmanlık yaklaşımımızda analiz fazının çıktısı yazılı bir kapsam belgesidir: modüller, uyarlamalar, taşınacak veri setleri ve entegrasyonlar tek tek listelenir.

Faz 2 — Kurulum, uyarlama ve yetki yapısı

Analiz onaylandıktan sonra sistem kurulur, şirket parametreleri (hesap planı, KDV ve tevkifat tanımları, döviz kurları, belge numaralandırma) yapılandırılır. Tiger'dan gelen şirketlerde hesap planı genellikle tek düzen hesap planına yakındır, bu tarafta sürpriz az olur; asıl emek kod yapılarında harcanır:

• Stok kartı kodlaması: Tiger'daki kod mantığı çoğu zaman yıllar içinde organik büyümüştür. Geçiş, kod yapısını rasyonalize etmek için tek fırsattır — bu fırsatı kullanmayan şirket, eski düzensizliği yeni sisteme taşır.
• Cari kodlama ve gruplama: Müşteri/tedarikçi ayrımı, satıcı bazlı gruplama ve ödeme koşulları SAP Business One'da iş kuralı üretir; baştan doğru kurgulanmalıdır.
• Boyut (dimension) ve masraf merkezi yapısı: Tiger'da rapor koduyla çözülen ihtiyaçların çoğu SAP tarafında maliyet muhasebesi boyutlarıyla karşılanır.

Bu fazda kullanıcı yetki matrisi de kurulur: kim hangi belgeyi açabilir, kim onaylar, kim fiyat değiştirebilir. Bunu canlıya geçtikten sonraya bırakmak, ilk haftalarda kaos üretir.

Faz 3 — Veri taşıma: projenin gerçek zorluğu

Veri taşıma her teklifte tek satırdır, her projede en çok zaman yiyen iştir. Tiger'dan SAP Business One'a tipik olarak şu setler taşınır:

Veri seti	Taşıma yaklaşımı	Tipik tuzak
Stok kartları	Temizlenip kod dönüşüm tablosuyla aktarılır	Mükerrer ve ölü kartlar, tutarsız birimler
Cari kartlar	Müşteri/tedarikçi ayrıştırılarak aktarılır	Aynı firmanın birden çok kartı, eksik vergi bilgileri
Açık kalemler	Açık fatura ve sipariş bazında	Kapanmış görünen ama bakiyesi olan belgeler
Stok bakiyeleri	Sayım sonucuyla, depo bazında	Sistem stoku ile fiili stok farkı
Muhasebe açılışı	Mizan bazında açılış fişi	Ara hesaplardaki birikmiş tutarlar

İki ilkeye sahada istisnasız uyuyoruz. Birincisi: hareket geçmişi taşınmaz, bakiye taşınır. Tiger'daki beş yıllık fatura geçmişini SAP'ye taşımak teknik olarak mümkün olsa da maliyeti faydasını aşar; eski sistem raporlama amaçlı okunabilir durumda tutulur. İkincisi: veri, kaynak sistemde temizlenir. Kirli veriyi taşıyıp yeni sistemde temizlemeye çalışmak, iki sistemde birden mutabakat bozmak demektir. Bu konuyu ayrı bir yazıda derinlemesine ele alıyoruz; ana veri hazırlığı geçiş projesinin sigortasıdır.

Faz 4 — Paralel dönem ve canlıya geçiş

Paralel çalışma dönemi, iki sistemin aynı anda yaşatıldığı kısa ve yorucu bir dönemdir: kritik belgeler (satış faturası, irsaliye, tahsilat) her iki sisteme de işlenir, gün sonunda sonuçlar karşılaştırılır. Amaç yazılımı test etmek değil — o iş test senaryolarıyla daha önce bitmiştir — kullanıcıların gerçek yük altında sisteme güvenmesini sağlamaktır.

Paralel dönem hakkında iki uyarımız var:

1. Süreyi kısa tutun. İki sisteme çift kayıt girmek ekibi hızla yıpratır; uzayan paralel dönem disiplini bozar ve karşılaştırma anlamını yitirir. Kapsama göre bir-iki haftalık, net bitiş tarihli bir paralel dönem planlayın.
2. Çıkış kriterini baştan yazın. "Kendimizi hazır hissedince geçeriz" bir kriter değildir. Mutabakat sağlanan belge tipleri, kapanan açık konular ve eğitimini tamamlamış kullanıcı listesi — geçiş kararı bu somut listeye bakılarak verilir.

Canlıya geçiş günü için önerdiğimiz desen: hafta sonu kesin veri aktarımı, pazartesi sabahı danışman ekibin yerinde veya çevrim içi hazır beklediği kontrollü açılış. İlk iki hafta yoğun destek dönemidir; kullanıcı sorularının çoğu bu dönemde gelir ve doğru cevaplanan her soru, kalıcı bir alışkanlığa dönüşür.

Tiger alışkanlıklarından SAP alışkanlıklarına

Geçişin yazılım dışı boyutu küçümsenmemeli. Tiger kullanıcısı fiş mantığıyla düşünür; SAP Business One belge akışı mantığıyla çalışır — teklif siparişe, sipariş irsaliyeye, irsaliye faturaya kopyalanır ve her adım izlenebilir kalır. Bu zihinsel geçiş, eğitimin asıl konusudur. Ekran eğitimi değil süreç eğitimi veriyoruz; kullanıcının "bu tuş nerede" sorusunu değil "bu iş artık nasıl akıyor" sorusunu cevaplıyoruz. Kullanıcı eğitimi hizmetimizin geçiş projelerindeki payı, çoğu şirketin baştan tahmin ettiğinden büyüktür.

15 yılı aşan saha deneyimimizde net bir desen var: geçişi başarıyla tamamlayan şirketlerin ortak özelliği güçlü bir anahtar kullanıcı ekibi. Her modül için, kendi bölümünün işini bilen ve proje boyunca haftada bir-iki gününü ayırabilen bir anahtar kullanıcı belirleyin; bu yatırımın geri dönüşü her fazda hissedilir.

Geçiş projesi kontrol listesi

Projeyi fazlara bağlayan, sahada kullandığımız kontrol listesinin özeti:

Sözleşme öncesi

• İhtiyaç analizi ve kapsam belgesi yazılı mı; modüller, entegrasyonlar ve taşınacak veri setleri tek tek sayılmış mı?
• Veri göçünde sorumluluk sınırı net mi: temizliği kim yapıyor, doğrulamayı kim imzalıyor?
• Lokalizasyon kalemleri (e-Fatura, e-İrsaliye, e-Defter) teklifte ayrı satırlar mı?
• Canlı sonrası destek modeli ve müdahale beklentisi sözleşmede yazıyor mu?

Analiz ve kurulum fazı

• Anahtar kullanıcılar belirlendi mi ve haftalık mesai taahhüdü yönetimce onaylandı mı?
• Tiger'daki süreçlerden hangilerinin standarda uyarlanacağı, hangilerinin özelleştirileceği kararlaştırıldı mı?
• Stok ve cari kod standardı yazılı olarak tanımlandı mı?
• Yetki matrisi ve onay akışları taslak olarak çıkarıldı mı?

Veri taşıma ve paralel dönem

• En az iki deneme yüklemesi planlandı mı; doğrulama kriterleri (kart adedi, bakiye toplamları) yazılı mı?
• Paralel dönemin süresi, kapsamı ve çıkış kriterleri belli mi?
• Eski sisteme veri girişinin ne zaman kapanacağı ilan edildi mi?

Canlıya geçiş

• Geçiş hafta sonuna planlandı mı; geri dönüş (rollback) senaryosu yazılı mı?
• İlk iki hafta için yoğun destek düzeni (yerinde/çevrim içi) kuruldu mu?
• Açık konu listesi tek bir yerde, sahipli ve tarihli izleniyor mu?

Bu listenin her maddesi, sahada en az bir projede canı yanmış bir şirketin dersidir. Maddelerin yarısından çoğu yazılıma değil sürece dairdir — geçiş projelerinin doğası budur.

Sık sorulan sorular

Logo Tiger'dan SAP Business One'a geçiş ne kadar sürer?

Kapsama bağlıdır: dar kapsamlı bir KOBİ geçişi tipik olarak 2-8 hafta, çok lokasyonlu ve entegrasyon yoğun projeler 8-12 ay sürer. Süreyi en çok etkileyen üç değişken veri temizliği, özelleştirme sayısı ve şirket içi karar hızıdır.

Tiger'daki eski faturalarımız ve hareket geçmişimiz SAP'ye taşınır mı?

Standart yaklaşımda taşınmaz; açık kalemler ve bakiyeler taşınır, geçmiş hareketler için eski sistem okunabilir arşiv olarak tutulur. Hareket geçmişini taşımak teknik olarak mümkündür ama maliyeti ve mutabakat riski, sağladığı faydayı neredeyse her zaman aşar.

Geçiş sırasında işimiz durur mu?

Hayır; proje mevcut sistem çalışırken yürür. Kesinti yalnızca canlıya geçiş anındaki veri aktarım penceresidir ve bunu hafta sonuna planlarız. Paralel dönemde çift kayıt disiplini ek mesai getirir, bunu baştan planlamak gerekir.

Mali yıl ortasında geçmek zorunda kalırsak ne olur?

Mümkündür ama açılış bakiyelerine ek olarak dönem içi hareketlerin de taşınması gerektiğinden veri taşıma ve mutabakat yükü artar. Takvimi seçme şansınız varsa dönem başını hedefleyin; geçiş planınızı birlikte netleştirmek için keşif görüşmesi yapabiliriz.