SAP Business One Kurulum Süresi Ne Kadar? Proje Takvimi Rehberi

Kurulum süresi neden her projede farklıdır?

SAP Business One'ın teknik kurulumu, projenin yalnız küçük bir adımıdır. Bir ERP projesinin takvimini belirleyen asıl iş; süreçlerin analiz edilmesi, hedef işleyişin tasarlanması, verinin hazırlanması, entegrasyonların kurulması, testlerin yapılması ve kullanıcıların sistemi gerçekten kullanır hâle gelmesidir. Bu nedenle aynı ürün, iki farklı işletmede çok farklı takvimlerle canlıya alınabilir.

"Şu kadar günde kurulur" ifadeleri genellikle yalnız yazılımın sunucuya kurulmasını tarif eder; finans, satış, satın alma, stok veya üretim süreçlerinizin sistemde çalışır hâle gelmesini değil. Sizin takviminiz, kapsam netleştikten sonra proje planıyla birlikte çıkar.

Takvimi belirleyen dört başlık şudur: hangi süreçler devreye alınacak, veri hangi durumda, kaç entegrasyon kurulacak ve ekip projeye ne kadar zaman ayırabilecek. Bu dördü netleştikçe süre de netleşir. Aşağıda projenin bütün aşamalarını, mantıklı fazlar hâlinde sırasıyla açıklıyoruz.

Faz 1: Keşif, mevcut durum analizi ve kapsam belirleme

Proje, keşif görüşmesiyle başlar. Keşif aşamasında işletmenin ne yaptığı, hangi departmanların hangi süreçleri yürüttüğü ve ERP'den beklentinin ne olduğu ortaya konur. Bu aşamada yönetimin beklentisiyle günlük operasyonun ihtiyacı birlikte değerlendirilir.

Mevcut durum analizi, süreçlerin bugün nasıl yürüdüğünü belge akışı düzeyinde çıkarır: sipariş nasıl alınıyor, stok nasıl düşülüyor, fatura nereden kesiliyor, hangi veri hangi Excel dosyasında tutuluyor, onay kim tarafından veriliyor. Mevcut durum ne kadar doğru çıkarılırsa sonraki aşamalar o kadar öngörülebilir planlanabilir.

Kapsam belirleme, proje takvimini en çok etkileyen kararlardan biridir. Hangi modüllerin ilk fazda devreye alınacağı, hangi süreçlerin sonraki faza bırakılacağı, hangi entegrasyonların ilk günden gerekli olduğu bu aşamada yazılı hâle getirilir. Kapsam yazılı değilse takvim de tahminden ibaret kalır.

• Keşif: beklentilerin, önceliklerin ve proje hedeflerinin ortaya konması.
• Mevcut durum analizi: bugünkü süreçlerin, belge akışlarının ve sistemlerin çıkarılması.
• Kapsam belirleme: ilk fazda devreye alınacak süreçlerin, modüllerin ve bağlantıların yazılı olarak netleştirilmesi.

Faz 2: Hedef süreç tasarımı ve altyapı hazırlığı

Hedef süreç tasarımı, "bugün nasıl çalışıyoruz" sorusundan "SAP Business One üzerinde nasıl çalışacağız" sorusuna geçiştir. Sipariş, satın alma talebi, üretim emri, sevkiyat ve fatura akışlarının sistemde hangi belgelerle, hangi sırayla ve hangi onaylarla ilerleyeceği tasarlanır. Mevcut alışkanlıkların bir kısmı sistemde birebir korunur, bir kısmı sadeleştirilir.

Bu aşamada verilen kararlar takvimin geri kalanını doğrudan belirler. Standarda yakın tasarımlar hızlı ilerler; işletmeye özgü istisnaların çokluğu ise konfigürasyon, geliştirme ve test eforunu büyütür. Bu nedenle tasarım aşamasında "bu istisna gerçekten gerekli mi, yoksa eski sistemin alışkanlığı mı" sorusu sık sık sorulur.

Altyapı hazırlığı tasarımla paralel yürür: sistemin bulutta mı yoksa kendi sunucunuzda mı çalışacağı, sunucu ve veritabanı kaynakları, ağ ve erişim kurgusu, yedekleme yaklaşımı ile test ve canlı ortamların ayrılması planlanır. Altyapı kararı geciktiğinde, hazır olan tasarım bile beklemek zorunda kalır.

• Hedef süreç tasarımı: belge akışlarının, onay noktalarının ve sorumlulukların SAP Business One üzerinde kurgulanması.
• Altyapı hazırlığı: bulut/on-premise kararı, sunucu ve veritabanı kaynakları, erişim, yedekleme, test ve canlı ortam planı.

Faz 3: SAP Business One kurulumu, temel konfigürasyon ve yetkiler

SAP Business One kurulumu, hazırlanan altyapı üzerinde sistemin ve veritabanının devreye alınması, istemci erişiminin sağlanması ve ortamların (test/canlı) ayağa kaldırılmasıdır. Altyapı hazırsa bu adım projenin en öngörülebilir aşamalarından biridir; takvimi belirleyen kısım kurulumun kendisi değil, sonrasında gelen uyarlama çalışmasıdır.

Temel konfigürasyon, sistemin işletmenize göre ayarlandığı aşamadır: şirket tanımı, mali dönem ve muhasebe yapısı, para birimleri, vergi kurguları, depo tanımları, belge numaralandırma, fiyatlandırma ve iskonto kuralları, onay akışları ve süreç ayarları. Faz 2'de tasarlanan işleyiş burada sistemde karşılığını bulur.

Kullanıcı ve yetki tasarımı, sıklıkla hafife alınan ama süreç kontrolünün omurgasını kuran adımdır. Kimin hangi ekranı göreceği, hangi belgeyi oluşturabileceği, hangi tutarın üzerinde onay gerekeceği burada tanımlanır. Yetki tasarımı ayrıca lisans rol dağılımıyla da doğrudan ilişkilidir; bu nedenle kapsamla birlikte ele alınır.

• SAP Business One kurulumu: sistem, veritabanı ve istemci erişiminin devreye alınması, test ve canlı ortamların hazırlanması.
• Temel konfigürasyon: şirket, mali dönem, vergi, depo, belge, fiyatlandırma ve onay ayarlarının işletmeye göre yapılandırılması.
• Kullanıcı ve yetki tasarımı: rollerin, ekran ve belge yetkilerinin, onay eşiklerinin tanımlanması.

Faz 4: Veri hazırlama, veri temizleme ve veri taşıma

Veri, ERP projelerinde takvimi en çok sürprizle karşılaştıran alandır. Veri hazırlama aşamasında hangi verilerin taşınacağı belirlenir: cari kartlar, stok kartları, ürün ağaçları, fiyat listeleri, açık siparişler, açık bakiyeler ve geçmiş hareketlerin ne kadarının aktarılacağı kararlaştırılır. "Her şeyi taşıyalım" yaklaşımı, çoğu projede gereksiz efor ve gereksiz risk üretir.

Veri temizleme, taşımadan önce yapılması gereken ve çoğunlukla işletmenin kendi ekibini gerektiren adımdır: mükerrer cari kayıtları, kullanılmayan stok kartları, eksik vergi/adres bilgileri, tutarsız birim ve kod yapıları burada düzeltilir. Kirli veri taşındığında sorun ortadan kalkmaz; yalnız yeni sisteme taşınmış olur.

Veri taşıma, hazırlanan ve temizlenen verinin şablonlarla sisteme aktarılması, ardından kontrol edilip mutabakatının yapılmasıdır. Taşıma genellikle tek seferde değil; önce test ortamında deneme aktarımı, sonra düzeltme, en sonunda canlıya geçiş sırasında nihai aktarım şeklinde ilerler. Bu aşamanın süresi, veri hacminden çok verinin kalitesine ve kaynak sistemlerden alınabilirliğine bağlıdır.

• Veri hazırlama: taşınacak veri kümesinin belirlenmesi ve kaynak sistemlerden çıkarılması.
• Veri temizleme: mükerrer, eksik ve tutarsız kayıtların düzeltilmesi, kod ve birim yapılarının standartlaştırılması.
• Veri taşıma: deneme aktarımı, kontrol, düzeltme ve nihai aktarım ile bakiye mutabakatı.

Faz 5: Entegrasyonlar, özel geliştirmeler ve raporlar

Entegrasyonlar, SAP Business One'ın çevresindeki sistemlerle konuşmasını sağlar: e-fatura/e-arşiv, banka hareketleri, e-ticaret platformları, depo ve saha uygulamaları, CRM veya üretim veri toplama sistemleri. Her entegrasyon kendi analizini, geliştirmesini, testini ve hata senaryosu kurgusunu gerektirir; bu nedenle entegrasyon sayısı takvimi doğrudan etkiler.

Özel geliştirmeler, standart işleyişin karşılamadığı ihtiyaçlar için devreye girer: işletmeye özgü ekranlar, alan doğrulamaları, otomatik hesaplamalar, özel belge çıktıları veya süreç otomasyonları. Buradaki temel ilke, standardın karşıladığı bir ihtiyacı geliştirmeyle çözmemektir; her gereksiz geliştirme hem takvimi hem sürdürme yükünü büyütür.

Raporlar, yönetimin sistemden gerçekten fayda gördüğü noktadır. Standart raporların yanında, işletmenin karar aldığı çıktılar (satış ve kârlılık analizleri, stok ve tedarik raporları, nakit ve alacak takibi, üretim performansı, yönetim gösterge tabloları) hazırlanır. Rapor beklentileri kapsamda erken yazılırsa, canlıya geçişten sonra "bu rapor yok" sürprizi yaşanmaz.

• Entegrasyonlar: bağlantı analizi, geliştirme, hata ve tekrar deneme senaryolarının kurgulanması, uçtan uca test.
• Özel geliştirmeler: standart dışı ihtiyaçlar için ekran, doğrulama, otomasyon ve çıktı geliştirmeleri.
• Raporlar: yönetim ve operasyon raporlarının, gösterge tablolarının hazırlanması ve doğrulanması.

Faz 6: Test, UAT ve kullanıcı eğitimleri

Test aşamasında kurgulanan sistem, gerçek verilerle ve gerçek senaryolarla denenir: teklif-sipariş-sevkiyat-fatura akışı baştan sona çalıştırılır, satın alma ve stok hareketleri kontrol edilir, üretim varsa üretim emri ve malzeme hareketleri doğrulanır, entegrasyonlar uçtan uca denenir. Amaç, hataları canlıda değil test ortamında bulmaktır.

UAT (kullanıcı kabul testi), sistemi danışmanın değil, işi yapan kullanıcının test etmesidir. Her departman kendi günlük işini sistemde yapar ve "bu akış benim işimi görüyor" onayını verir. UAT'nin ciddiye alınmadığı projelerde sorunlar canlıya geçişten sonra ortaya çıkar ve o noktada çözüm maliyeti çok daha yüksektir. UAT'ye kullanıcıların ayırdığı zaman, takvimin en kritik girdilerinden biridir.

Kullanıcı eğitimleri rollere göre ve uygulamalı yapılır: finans ekibi kendi ekranlarını, satış ekibi kendi akışını, depo ekibi kendi hareketlerini çalışır. Eğitimin canlıya geçişe yakın zamanlanması, öğrenilenin taze kalmasını sağlar. Eğitim, sistemin kullanılmasının ön koşuludur; atlandığında proje teknik olarak biter ama pratikte başlamaz.

• Test: süreçlerin, belge akışlarının, raporların ve entegrasyonların gerçek senaryolarla denenmesi.
• UAT: kullanıcıların kendi işlerini sistemde yaparak kabul onayı vermesi.
• Kullanıcı eğitimleri: role göre uygulamalı eğitim ve kullanım dokümanlarının teslimi.

Faz 7: Geçiş hazırlığı, canlıya geçiş ve canlı sonrası destek

Geçiş hazırlığı (cutover), geçişin adım adım planlanmasıdır: eski sistemde işlem girişinin ne zaman durdurulacağı, açılış bakiyelerinin ve açık belgelerin nasıl aktarılacağı, sayımın ne zaman yapılacağı, hangi adımın kimin sorumluluğunda olduğu ve bir sorun çıkarsa geri dönüş planının ne olacağı yazılı hâle getirilir. İyi bir geçiş planı, geçiş gününü sürprizden arındırır.

Canlıya geçiş, nihai veri aktarımının yapıldığı, açılış bakiyelerinin doğrulandığı ve kullanıcıların artık gerçek işlerini yeni sistemde girmeye başladığı andır. Bu dönemde sistemin yanında olmak kritiktir: ilk faturalar, ilk sevkiyatlar, ilk üretim emirleri ve ilk mutabakatlar yakından izlenir.

Hypercare (canlı sonrası destek), geçişten sonraki yoğun destek dönemidir. Kullanıcı soruları hızlı yanıtlanır, küçük düzeltmeler yapılır, raporlar rafine edilir ve ilk dönem kapanışı birlikte doğrulanır. Hypercare tamamlandığında proje, planlı destek ve sürekli iyileştirme moduna geçer. Bu son aşama takvime dâhil edilmediğinde, proje kâğıt üzerinde biter ama işletmede oturmamış olur.

• Geçiş hazırlığı: geçiş planı, sorumluluk dağılımı, açılış bakiyeleri, sayım ve geri dönüş senaryosu.
• Canlıya geçiş: nihai veri aktarımı, açılış doğrulaması ve gerçek işlemlerin yeni sistemde başlaması.
• Canlı sonrası yoğun destek: kullanıcı soruları, düzeltmeler, raporların rafine edilmesi ve ilk dönem kapanışının doğrulanması.

Takvimi uzatan ve kısaltan etkenler

Aynı modül kapsamıyla başlayan iki proje, aşağıdaki değişkenler yüzünden çok farklı sürelerde canlıya geçebilir. Bu etkenlerin çoğu teknik değil, organizasyoneldir:

• Müşteri tarafı hazırlık: proje için ayrılmış bir sorumlu ve departman temsilcileri varsa süreç akıcı ilerler; herkesin "asıl işinden arta kalan zamanda" ilgilendiği projeler uzar.
• Veri kalitesi: temiz, tek kaynaktan alınabilen veri taşımayı hızlandırır; dağınık, mükerrer ve eksik veri hem taşımayı hem testi geciktirir.
• Karar hızı: kapsam, süreç ve istisna kararlarının hızlı ve yetkili biçimde verilmesi takvimi kısaltır; bekleyen her karar, bağlı bütün adımları durdurur.
• Kaynak ayırma: kullanıcıların analiz, UAT ve eğitim için gerçekten zaman ayırabilmesi belirleyicidir; test edilmeyen bir sistem canlıya alınamaz.
• Kapsam kayması: proje sırasında sürekli yeni istek eklenmesi, tamamlanmış adımların yeniden açılmasına ve takvimin sürekli ötelenmesine yol açar.
• Entegrasyon ve geliştirme yoğunluğu: karşı sistemlerin arayüz olanakları ve üçüncü taraf tedarikçilerin yanıt hızı, kontrolünüz dışında gecikme üretebilir.
• Üretim ve MRP kapsamı: ürün ağaçları, rotalar ve planlama kurguları hem analizi hem veri hazırlığını hem testi derinleştirir.

Kendi tarafınızda ne yaparsanız süreç hızlanır?

Bir ERP projesinin takvimi, danışmanlık tarafının hızı kadar işletmenin hazırlığına bağlıdır. Aşağıdaki başlıklar, projeye başlamadan önce bile ilerletebileceğiniz ve takvimi doğrudan kısaltan hazırlıklardır:

• Proje sorumlusu atayın: karar toplayan, ekipleri koordine eden ve tek muhatap olan bir kişi belirleyin.
• Departman temsilcilerini netleştirin: finans, satış, satın alma, depo ve üretim için kararı verebilecek isimleri baştan belirleyin.
• Verinizi erkenden temizleyin: cari ve stok kartlarındaki mükerrer, eksik ve güncel olmayan kayıtları proje beklemeden düzeltin.
• Mevcut belge ve rapor örneklerini toplayın: bugün kullandığınız formlar, çıktılar ve yönetim raporları analiz süresini belirgin biçimde kısaltır.
• Karar mekanizmasını hızlandırın: kapsam ve süreç kararları için düzenli, kısa ve yetkili bir toplantı ritmi kurun.
• Kullanıcı zamanını takvimde ayırın: analiz, UAT ve eğitim için kullanıcıların takviminde gerçek zaman blokları oluşturun.
• Kapsamı yazılı tutun: yeni istekleri reddetmek yerine "faz 2" listesine alın; böylece hem ihtiyaç kaybolmaz hem canlıya geçiş gecikmez.
• Entegrasyon muhataplarını erken devreye alın: e-ticaret, banka veya depo sistemlerinin tedarikçileriyle teması projenin başında kurun.

Fazlı yaklaşım: önce çekirdek süreçler, sonra genişleme

Bütün süreçleri aynı anda canlıya almak, teorik olarak mümkün ama pratikte çoğu işletme için en riskli yoldur. Kapsam büyüdükçe test yükü, eğitim yükü ve geçiş riski birlikte büyür; ayrıca projenin faydası ilk çıktının alınacağı ana kadar ertelenmiş olur.

Yaygın ve sağlıklı yol, çekirdek süreçlerle başlamaktır: finans, satış, satın alma ve stok. Bu çekirdek oturduğunda işletme zaten tek veri modeliyle çalışmaya başlar. Ardından üretim ve MRP, servis yönetimi, ileri raporlama, ek entegrasyonlar ve özel geliştirmeler ikinci fazda eklenir.

Fazlı yaklaşımın ikinci avantajı öğrenme etkisidir: ilk fazda sistemi kullanmayı öğrenen ekip, ikinci fazın analizine çok daha isabetli katkı verir. İlk fazda "olsa iyi olur" diye eklenen isteklerin bir kısmının ikinci fazda gereksiz olduğu görülür; bu da hem takvimi hem bütçeyi korur.

Fazlandırma kararı keşif aşamasında verilir ve kapsam belgesine yazılır. Hangi sürecin hangi fazda olduğu net değilse, faz ayrımı pratikte işlemez ve proje tek büyük fazın riskiyle ilerler.

Senaryo 1: Standart finans, satış, satın alma ve stok projesi

Üretimi olmayan, süreçleri görece standart ilerleyen bir ticaret veya hizmet işletmesi düşünün: teklif ve sipariş alınıyor, satın alma yapılıyor, stok tek veya birkaç depoda takip ediliyor, faturalama ve muhasebe akışı standarda yakın çalışıyor.

Bu profilde analiz kapsamı dardır, hedef süreç tasarımı daha az istisna içerir, veri kümesi çoğunlukla cari ve stok kartları ile açık bakiyelerden oluşur ve eğitim ihtiyacı sınırlı sayıda role dağılır. Üç senaryo içinde en kısa ve en öngörülebilir takvim bu profilde ortaya çıkar.

Takvimi burada uzatan tek şey genellikle veri kalitesidir: yıllar içinde birikmiş mükerrer cari ve stok kayıtları, temizlenmediğinde en sade projeyi bile bekletir.

Senaryo 2: Üretim ve MRP içeren proje

Ürün ağaçları, üretim emirleri, iş merkezleri ve malzeme ihtiyaç planlaması devreye girdiğinde proje karakter değiştirir. Analiz artık yalnız belge akışını değil, üretimin nasıl planlandığını, malzemenin nasıl tüketildiğini ve maliyetin nasıl oluştuğunu da kapsar.

Veri tarafı belirgin biçimde büyür: ürün ağaçlarının doğruluğu, yarı mamul tanımları, rotalar, iş merkezi kapasiteleri ve maliyet verileri hazırlanmalıdır. Bu veriler çoğu işletmede tek bir sistemde değil, üretim müdürünün ve mühendislik ekibinin bilgisinde dağınık hâlde durur; toplanması ve doğrulanması zaman ister.

Test ve UAT eforu da artar: bir üretim emrinin açılması, malzeme çekilmesi, hurda ve fire kaydı, yarı mamul girişleri ve maliyet yansımaları uçtan uca denenmelidir. Bu nedenle üretimli bir proje, aynı kullanıcı sayısındaki standart bir projeye kıyasla belirgin biçimde daha uzun bir takvim gerektirir. Bu profilde fazlı yaklaşım özellikle işe yarar: önce çekirdek finans ve lojistik, sonra üretim ve planlama.

Senaryo 3: Yoğun entegrasyon ve özel geliştirme içeren proje

Üçüncü profil, SAP Business One'ın çok sayıda sistemle çift yönlü konuştuğu kurgudur: e-ticaret platformları, pazaryerleri, banka hareketleri, depo/barkod uygulamaları, CRM veya saha ekiplerinin kullandığı mobil çözümler. Buna işletmeye özgü ekranlar ve otomasyonlar da eklenebilir.

Bu senaryoda takvimi belirleyen şey ERP tarafı değil, bağlantıların kendisidir. Her entegrasyon; karşı sistemin arayüz olanaklarının incelenmesini, veri eşleme kurallarının yazılmasını, hata ve tekrar deneme senaryolarının kurgulanmasını ve uçtan uca testini gerektirir. Üstelik bu adımların bir kısmı, karşı tarafın tedarikçisinin yanıt hızına bağlıdır; yani takvimin bir bölümü sizin kontrolünüz dışındadır.

Özel geliştirmeler de aynı mantıkla ilerler: analiz, geliştirme, test ve kullanıcı onayı. Bu profil üç senaryonun en geniş takvimini gerektirir; buna karşılık elle veri girişinin ve mükerrer işin en çok azaldığı profil de budur. Doğru strateji, entegrasyonların tamamını ilk faza yığmak yerine kritik olanlarla başlamak ve kalanını ikinci faza planlamaktır.

Sizin projenizin takvimi nasıl netleşir?

Gerçekçi bir takvim, ürün broşüründen değil kapsam çalışmasından çıkar. Keşif ve analiz tamamlandığında; hangi süreçlerin ilk fazda olduğu, hangi verinin taşınacağı, kaç entegrasyonun kurulacağı, hangi geliştirmelerin gerektiği ve kullanıcıların projeye ne kadar zaman ayırabileceği bilinir. Bu girdilerle hazırlanan plan, aşama aşama tarihlendirilebilir bir takvim üretir.

Bu nedenle bir iş ortağından takvim isterken kapsamı da birlikte konuşun. Kapsam netleşmeden verilen süre taahhütleri iyi haber gibi görünür; ama proje ortasında kapsamla çeliştiğinde hem takvim hem güven zarar görür.

Süreçlerinizi birlikte gözden geçirdiğimiz kısa bir keşif görüşmesi, projenizin fazlarını ve gerçekçi takvimini çıkarmak için yeterli başlangıçtır.

Sık Sorulan Sorular