2027 yaklaşırken: S/4HANA geçişinde karar vermeniz gereken 5 başlık

SAP, ECC 6.0 için ana bakım desteğini 2027 sonunda bitiriyor. Uzatılmış destek 2030'a kadar ek maliyetle sürüyor, ama bu bir çözüm değil, sadece süre satın almak. Tipik bir dönüşüm projesi hazırlıktan canlıya geçişe 9 ila 18 ay sürdüğü için, karar penceresi göründüğünden dar.

Sahada gördüğümüz en yaygın hata, işe teknik bir kurulum sorusu olarak başlamak: “brownfield mi greenfield mi?” Bu soru önemli, ama sırası ikinci. Önce aşağıdaki beş başlığın netleşmesi gerekir; teknik yaklaşım zaten bu cevaplardan çıkar.

1. Mevcut özel geliştirmelerinizin ne kadarı gerçekten kullanılıyor?

Yıllar içinde biriken Z programları, kullanıcı çıkışları ve raporlar çoğu şirkette envanteri çıkarılmamış bir yük oluşturur. Geçiş projelerinde bu kodun tamamını taşımaya çalışmak, hem süreyi hem maliyeti ikiye katlar.

Başlangıç noktası kullanım analizidir: son 12–24 ayda hangi özel nesne kaç kez çalıştı, kim çalıştırdı. Uygulamada bu listenin önemli bir bölümünün hiç kullanılmadığını ya da standart S/4HANA fonksiyonuyla karşılanabilir olduğunu görüyoruz. Taşınacak kod listesi küçüldükçe proje riski doğrusal olarak azalır.

2. Ana veriniz taşınmaya hazır mı?

S/4HANA'nın iş ortağı (business partner) yaklaşımı, müşteri ve satıcı ana verisini tek bir yapıda birleştirir. Mevcut sistemde mükerrer kartlar, eksik vergi bilgileri veya tutarsız hesap grupları varsa, bunlar geçişte bir anda görünür hale gelir.

Ana veri temizliği geçişin en çok küçümsenen kalemidir. Projeye paralel yürütülebilir ama başlangıcı ertelenmemelidir; çünkü temizlik kararları (hangi kart birleşecek, hangisi kapanacak) iş birimlerinin onayını gerektirir ve bu onaylar zaman alır.

3. Finansal süreçlerinizde hangi yerel gereklilikler kritik?

Türkiye'de e-fatura, e-defter, enflasyon muhasebesi ve KDV iade süreçleri; çok ülkeli yapılarda ise her ülkenin kendi yasal raporlaması geçiş kapsamını doğrudan etkiler. Bu gereklilikler standart S/4HANA'da tam karşılanmadığında, yerine ne konacağı önceden planlanmalıdır.

Kritik nokta şudur: yasal uyum kalemleri projenin sonunda “ek geliştirme” olarak ortaya çıkarsa, canlıya geçiş tarihi kayar. Bu başlığı kapsam çalışmasının en başına almak, sonradan yaşanan sürprizlerin çoğunu ortadan kaldırır.

4. Geçiş sırasında işi kim yürütecek?

Dönüşüm projeleri, iş birimlerinin en deneyimli kişilerini ister; ancak aynı kişiler günlük operasyonu da yürütür. Bu çakışma planlanmadığında proje ya yavaşlar ya da operasyon aksar.

Pratik çözüm, proje ekibine ayrılan zamanı baştan tanımlamak ve günlük destek yükünü bu dönemde dışarıdan karşılamaktır. Destek (AMS) modeli devrede olan şirketlerde dönüşüm projeleri gözle görülür biçimde daha az sarsıntıyla ilerliyor; çünkü ekip “bugünü” değil “yarını” düşünebiliyor.

5. Geçişten sonra ne kazanmayı bekliyorsunuz?

En zor soru bu. “Destek bitiyor, geçmek zorundayız” geçerli bir gerekçedir ama tek başına projeyi yönlendirmez. Ölçülebilir bir hedef — kapanış süresini 8 günden 4 güne indirmek, stok doğruluğunu artırmak, raporlamayı Excel'den çıkarmak — kapsam tartışmalarında pusula işlevi görür.

Hedefi baştan koymayan projelerde kapsam, en yüksek sesin isteklerine göre şekillenir. Ölçülebilir hedefi olan projelerde ise “bu geliştirme hedefe hizmet ediyor mu?” sorusu, kapsamı kendiliğinden disipline eder.

Nereden başlamalı?

Bu beş başlığın cevabı, hangi geçiş yaklaşımının size uyduğunu da belirler. Mevcut süreçleri büyük ölçüde koruyacaksanız ve öncelik süreyse dönüşüm (brownfield); süreçleri yeniden kurgulayacaksanız yeni kurulum (greenfield) daha uygun olabilir. İkisinin arasında, seçmeli veri taşımayla ilerleyen yaklaşımlar da var.

Karar vermeden önce sisteminizin mevcut durumunun fotoğrafını çekmenizi öneririz: özel geliştirme envanteri, ana veri kalitesi, süreç olgunluğu ve yasal uyum kalemleri. Bu fotoğraf olmadan hazırlanan takvimler, projenin ortasında revize edilmek zorunda kalıyor.