Teknik rehber
Dönüşüm öncesinde hangi teknik belirsizlikler görünür hâle getirilmelidir?
Görünür olması gereken belirsizlikler; ürün ve sürüm kapsamı, özel kod, entegrasyonlar, veri ve arşiv, yetki, operasyon ve destek, bağımlılıklar, test edilebilirlik, geri dönüş ve karar sahipliği alanlarına dağılır. Amaç hepsini hemen çözmek değildir. Amaç, her birini bir etki düzeyine ve bir karar sahibine bağlayarak planın hangi varsayımlara dayandığını göstermektir.
- Hazırlayan Castintech
- Son doğrulama 23 Eylül 2026
- 9 dk okuma
- Kaynakça
Bu rehberde
Bölümler
Kapsam. Bu rehber, SAP® yazılımı dönüşümleri öncesinde teknik belirsizlikleri ele almak için genel bir çerçevedir. Bakım takvimine ilişkin bilgiler, geçerli oldukları ürün kapsamıyla ve resmî kaynağa bağlanarak verilmiştir; kendi sürüm ve sözleşme durumunuza göre ayrıca doğrulanmalıdır. Diğer bölümler Castintech’in değerlendirme çerçevesidir.
Belirsizlik ile risk arasındaki fark nedir?
Risk, olasılığı ve etkisi az çok tahmin edilebilen bir olaydır. Belirsizlik ise o tahmini yapmak için gereken bilginin eksik olmasıdır. “Bu arayüzün yeni sürümde çalışıp çalışmayacağını bilmiyoruz” bir belirsizliktir; kanıt toplandığında ya ortadan kalkar ya da ölçülebilir bir riske dönüşür. Dönüşüm hazırlığının önemli bir kısmı bu dönüşümü bilinçli olarak yapmaktır.
Görünmeyen belirsizlik, plana gizli bir varsayım olarak girer. Takvim, bütçe ve kapsam bu varsayımın doğru olduğu kabul edilerek hazırlanır; varsayım yanlış çıktığında planın hangi kısmının etkileneceği bilinmez.
Belirsizlikler nasıl sınıflandırılır?
Her belirsizlik iki eksende değerlendirilir: plana veya karara etkisi ve giderilme kolaylığı. Buna iki bilgi eklenir: kararı kimin vereceği ve cevabın en geç ne zaman gerektiği. Bu dört bilgi, hangi belirsizliğe önce kaynak ayrılacağını belirler ve emeğin kararı en çok değiştirebilecek bilgiye yönelmesini sağlar.
| Kolay giderilir | Zor giderilir | |
|---|---|---|
| Etkisi yüksek | Hemen gider; kararı bekletmesine izin verme | Erken başla, karar sahibine taşı, çalışma varsayımını yaz |
| Etkisi düşük | Planlı bir adımda gider | Varsayım olarak kaydet ve izle |
Diyagramın metin açıklaması
Başlangıç: belirsizliğin çıktığı on alan; ürün ve sürüm kapsamı, özel kod, entegrasyonlar, veri ve arşiv, yetki, operasyon ve destek, bağımlılıklar, test edilebilirlik, geri dönüş ve iş sürekliliği, karar sahipliği. On alan tek bir toplayıcıda birleşir; her belirsizlik bir kayıttır. Belirsizlik kaydı neyin bilinmediğini tek cümleyle yazar ve yedi alan taşır: etki, giderilme kolaylığı, karar sahibi, gereken tarih, çalışma varsayımı (varsayım işaretli), kapanış kanıtı (kanıt işaretli) ve durum: açık, gideriliyor, risk olarak kaydedildi, kapandı. Etki ve giderilme kolaylığı önceliklendirme alanına gider: etkisi yüksek ve kolay giderilen hemen giderilir; etkisi yüksek ve zor olan için erken başlanır, karar sahibine taşınır ve çalışma varsayımı yazılır; etkisi düşük ve kolay olan planlı bir adımda giderilir; etkisi düşük ve zor olan varsayım olarak kaydedilip izlenir. Kapanış kanıtı kapanışa gider: önceden yazılmış ölçüt karşılandığında kapanır, kapanış kaydı yoksa belirsizlik açık sayılır. Üç kapanış biçimi vardır: giderildi, ölçülebilir riske dönüşüp risk kaydına aktarıldı veya karar sahibi tarafından varsayım olarak kabul edildi ve izlenmeye devam ediyor. Bitiş: dört eşit ağırlıklı planlama girdisi dönüşüm kararında birleşir: iş hedefleri, belirsizliklerin durumu, teknik hazırlık ve bakım takvimi. Bakım takvimi bir planlama girdisidir; kararı tek başına belirlemez ve aciliyet nedeni değildir. Sınır: bakım takvimindeki her tarih, geçerli olduğu ürün kapsamıyla ve kurumun kendi sürüm ve sözleşme durumuyla doğrulanır. Diyagramda tarih yazılmaz ve döngü yoktur. Mobilde diyagram dört sıralı panelde okunur: 1/4 on alan, 2/4 belirsizlik kaydı, 3/4 önceliklendirme ve kapanış, 4/4 dönüşüm kararı. Künye: Castintech, D5, Eylül 2026; teknik anlatım diyagramı, SAP® ürün arayüzü değildir.
Alan alan hangi sorular sorulmalı?
Ürün ve sürüm kapsamı
- Bugün kurulu olan ürünler, sürümler ve enhancement package düzeyleri kayıtlı mı?
- Hedef ürün ve sürüm netleşti mi; örneğin SAP S/4HANA® yazılımının hangi sürümü ve hangi işletim modeli?
- Kullanılan yeteneklerin hedef üründe karşılığı doğrulandı mı?
- Lisans kapsamı, planlanan araç ve servisleri içeriyor mu?
Özel kod
- ABAP® programlama diliyle yazılmış özel kodun kullanım, sahiplik ve bağımlılık envanteri var mı?
- SAP S/4HANA geçişi için sunulan ve ABAP Test Cockpit (ATC) üzerinden çalışan kontroller [3], kurulu sürümde kullanılabilir mi?
- Hangi özel kod birimleri emekliye ayrılabilir, hangileri uyarlanmalı?
Yöntem: Özel kod envanterinin değerlendirilmesi.
Entegrasyonlar
- Tüm arayüzlerin listesi, yönü, karşı tarafı ve sahibi biliniyor mu?
- Hangi arayüz hedef üründe aynı biçimde kullanılabilir, hangisi değişecek?
- Karşı sistemlerin değişikliğe hazır olup olmadığı soruldu mu?
Tasarım ilkeleri: Entegrasyonlarda hata yönetimi ve güvenli tekrar işleme.
Veri ve arşiv
- Taşınacak verinin hacmi, kalitesi ve saklama gereksinimleri biliniyor mu?
- Arşivlenmiş veriye dönüşümden sonra nasıl erişilecek?
- Veri temizliği dönüşümden önce mi, sırasında mı yapılacak; kim onaylayacak?
Yetki
- Mevcut rol ve yetki yapısı belgelenmiş mi?
- Hedef üründe rol yapısı nasıl kurulacak; görevler ayrılığı kuralları nasıl korunacak?
- Teknik ve entegrasyon kullanıcılarının yetkileri gözden geçirildi mi?
Operasyon ve destek
- Dönüşüm sonrası sistemi kim işletecek; izleme ve olay yönetimi nasıl kurulacak?
- Destek ekibinin yeni ürün ve süreçler için hazırlığı planlandı mı?
- İşletim modelindeki değişiklikler (örneğin barındırma veya sorumluluk dağılımı) yazılı mı?
Bağımlılıklar
- Üçüncü taraf eklentilerin hedef sürümle uyumluluğu ve destek durumu doğrulandı mı?
- Altyapı, ağ ve güvenlik bileşenlerindeki bağımlılıklar biliniyor mu?
- Aynı dönemde yürüyen başka projeler dönüşümü etkiliyor mu?
Test edilebilirlik
- Kritik süreçler için test senaryoları ve kabul ölçütleri var mı?
- Testte kullanılacak veri, gerçek hacim ve çeşitliliği temsil ediyor mu?
- Otomatik test kapsamı hangi süreçlerde var, hangilerinde yok?
Geri dönüş ve iş sürekliliği
- Geçiş sırasında hangi noktada geri dönme kararı verilebilir; kimin kararıyla?
- Geri dönüşün ölçütleri önceden yazıldı mı?
- Kesinti penceresinde kritik süreçler nasıl sürdürülecek?
Karar sahipliği
- Her alan için karar sahibi adlandırıldı mı?
- Karar sahipleri arasında çatışma olduğunda kim karar veriyor?
- Kararların ve gerekçelerinin kaydı nerede tutuluyor?
Kurulu ürün, sözleşme kapsamı ve teknik kapsam nasıl ayrılır?
Bu üç kavram çoğu zaman aynı şeymiş gibi konuşulur, ancak farklı sorulara cevap verir ve farklı kanıtlarla doğrulanır. Kurulu ürün kaydı sistemde gerçekte ne bulunduğunu, sözleşme kapsamı kurumun hangi ürün ve hizmetleri kullanma hakkı olduğunu, teknik kapsam ise dönüşümde neyin gerçekten ele alınacağını gösterir. Aralarındaki her uyumsuzluk bir belirsizlik olarak kaydedilir.
| Kavram | Cevapladığı soru | Tipik kanıt | Tipik sahip |
|---|---|---|---|
| Kurulu ürün kaydı | Sistemde hangi ürün, sürüm ve enhancement package düzeyi var? | Sistemden alınan sürüm bilgisi ve ortam listesi | Teknik ekip |
| Sözleşme kapsamı | Kurum hangi ürün ve hizmetleri hangi koşullarla kullanabilir? | Sözleşme ve lisans belgeleri | Satın alma ve hukuk |
| Teknik kapsam | Dönüşümde hangi sistemler, süreçler ve nesneler ele alınacak? | Onaylanmış kapsam belgesi, envanter ve arayüz listesi | Dönüşüm ekibi ve süreç sahipleri |
Örneğin kurulu olduğu hâlde kullanılmayan bir bileşen teknik kapsamdan bilinçli olarak çıkarılabilir; sözleşme kapsamında olmayan bir hizmet ise hedef mimaride kullanılmadan önce ayrıca değerlendirilir. Bu değerlendirme teknik ekibin değil, sözleşmenin sahibinin kararıdır.
Bakım takvimi bilgileri nasıl doğru kapsamla kullanılır?
Bakım takvimi, dönüşümün zamanlamasında bir planlama girdisidir; tek başına bir dönüşüm gerekçesi veya aciliyet nedeni değildir. Her tarih, geçerli olduğu ürün kapsamıyla birlikte kullanılmalı ve kurumun kendi sürüm ve sözleşme durumuna göre ayrıca doğrulanmalıdır. Bu rehberde yalnız iki ayrı resmî SAP kaynağında doğrulanan bilgiler yer alır [1][2].
| Bilgi | Ürün kapsamı | Kaynak |
|---|---|---|
| Ana bakım 31 Aralık 2027’de sona erer. | SAP Business Suite 7 çekirdek uygulamalarının son üç enhancement package’ı; SAP kaynağında bu kapsamda SAP ERP 6.0 dahil çekirdek uygulamalar sayılır. | [1] [2] |
| İsteğe bağlı ek bakım dönemi 1 Ocak 2028 – 31 Aralık 2030’dur. | Aynı kapsam. | [1] [2] |
| Ek bakım ek ücretlidir. | Aynı kapsam. | [1] [2] |
| Bakım taahhüdü 2040’a uzanır. | SAP S/4HANA | [1] [2] |
Bu bilgileri kullanırken dikkat edilecekler:
- Takvimdeki kapsamın kendi sisteminiz için geçerli olup olmadığı, kurulu ürün ve enhancement package düzeyine göre doğrulanmalıdır.
- SAP S/4HANA taahhüdünün kullandığınız sürüm için ne anlama geldiği, sürüme özel bakım bilgisiyle ayrıca doğrulanmalıdır.
- Ek bakımın koşulları kurumun SAP ile yaptığı sözleşmeye bağlıdır ve bu rehberin kapsamı dışındadır.
- Takvim, dönüşüm kararını tek başına belirlememelidir. Karar; iş hedefleri, teknik hazırlık ve bu rehberdeki belirsizliklerin durumu ile birlikte verilir.
Belirsizlik kaydı nasıl tutulur?
| Alan | Açıklama |
|---|---|
| Kimlik | Kısa ve benzersiz bir kayıt numarası |
| Alan | Ürün kapsamı, özel kod, entegrasyon, veri, yetki, operasyon, bağımlılık, test, geri dönüş, karar sahipliği |
| Belirsizlik | Neyin bilinmediği, tek cümleyle |
| Etki | Plana veya karara etkisi: yüksek veya düşük, gerekçesiyle |
| Giderme yolu | Hangi kanıtla giderileceği ve bunun ne kadar kolay olduğu |
| Karar sahibi | Adlandırılmış rol |
| Gereken tarih | Cevabın en geç ne zaman gerektiği |
| Çalışma varsayımı | Cevap gelene kadar plan hangi varsayımla ilerliyor |
| Durum | Açık, gideriliyor, risk olarak kaydedildi, kapandı |
Bir belirsizlik hangi kanıtla kapatılmış sayılır?
Bir belirsizlik, onu açarken yazılan kapanış ölçütü karşılandığında kapanır. Ölçüt önceden yazılmazsa belirsizlikler kanıt yerine zamanla ya da bir toplantı kararıyla kapanmış görünür. Kapanış kaydı; kullanılan kanıtı, kanıtın tarihini, kapatan kişiyi ve kapanışın plana etkisini içerir; bu kayıt olmadan belirsizlik açık sayılır.
Kanıt türü belirsizliğin alanına göre değişir: sistemden alınan kayıt, resmî ürün belgesi, bir testin sonucu, sözleşme sahibinin veya eklenti sağlayıcısının yazılı teyidi ya da karar sahibinin yazılı kararı. Her belirsizlik üç biçimde kapanabilir: gerçekten giderilmiş olabilir, ölçülebilir bir riske dönüşüp risk kaydına aktarılmış olabilir veya karar sahibi tarafından bilinçli olarak varsayım şeklinde kabul edilmiş olabilir. Üçüncü durumda varsayım izlenmeye devam eder.
Belirsizlikler yönetime nasıl sunulur?
Yönetime sunulan görünüm kaydın tamamı değil, karar gerektiren kısmıdır. Alan bazında açık belirsizlik sayısı yerine etkisi yüksek olanlar tek tek gösterilir: ne bilinmiyor, karar sahibi kim, cevap en geç ne zaman gerekli ve cevap gelene kadar plan hangi varsayımla ilerliyor. Her biri için, varsayım yanlış çıkarsa planın hangi kısmının etkileneceği de yazılır.
Her şeyi tek bir risk puanıyla özetlemek cazip görünebilir; ancak bu, farklı nitelikteki belirsizlikleri aynı ölçeğe indirger ve hangi kararın beklendiğini gizler. Bu nedenle sunum, yönetimden beklenen kararlarla biter: hangi belirsizliğe kaynak ayrılmalı, hangi varsayım kabul edilmeli, hangi karar ertelenebilir. Teknik ayrıntı kayıtta kalır ve gerektiğinde açılır.
Sık yapılan yanlış varsayımlar
- “Belirsizlikler giderilmeden plan yapılamaz.” Yapılabilir; yeter ki hangi varsayımlarla yapıldığı yazılı olsun ve varsayımlar izlensin.
- “Teknik belirsizlikler teknik ekibin işidir.” Çoğu belirsizliğin karar sahibi iş tarafındadır: veri saklama, rol yapısı, kesinti penceresi gibi.
- “Bakım takvimi dönüşüm tarihini belirler.” Takvim bir girdidir; hazırlık düzeyi ve iş hedefleriyle birlikte değerlendirilir.
- “Üçüncü taraf eklentiler uyumludur.” Uyumluluk ve destek durumu her eklenti için ayrıca doğrulanmalıdır.
- “Geri dönüş planı, işlerin kötü gideceğini varsaymaktır.” Geri dönüş ölçütleri, işler kötü gitmeden önce kararın nasıl verileceğini tanımlar.
Kontrol listesi
- On alanın her biri için sorular cevaplandı veya belirsizlik olarak kaydedildi
- Her belirsizlik etki ve giderilme kolaylığına göre sınıflandırıldı
- Her belirsizliğin bir karar sahibi ve gereken tarihi var
- Her belirsizlik için kapanış ölçütü yazıldı
- Yüksek etkili belirsizlikler için çalışma varsayımı yazıldı
- Kurulu ürün, sürüm ve enhancement package düzeyleri kayda geçti
- Kurulu ürün kaydı, sözleşme kapsamı ve teknik kapsam ayrı ayrı kaydedildi
- Bakım takvimi bilgileri ürün kapsamıyla birlikte ve kaynağından doğrulanarak kullanıldı
- Özel kod envanteri ve arayüz listesi mevcut
- Üçüncü taraf eklentilerin uyumluluğu soruldu
- Kritik süreçler için test senaryoları ve kabul ölçütleri tanımlandı
- Geri dönüş karar noktası ve ölçütleri yazıldı
Sınır notları
Bu rehber genel teknik açıklamadır. Bakım takvimi bilgileri iki ayrı resmî SAP kaynağına dayanır ve yalnız belirtilen ürün kapsamı için geçerlidir; kaynaklar zamanla güncellenebilir. Sınıflandırma yöntemi, alan soruları ve belirsizlik kaydı Castintech’in değerlendirme çerçevesidir ve SAP’nin görüşü olarak okunmamalıdır. Belirli bir dönüşüm süresi, maliyeti veya sonucu iddia etmiyoruz.
Sık sorulan sorular
Belirsizlikler giderilmeden dönüşüm kararı verilebilir mi?
Evet. Kararlar çoğu zaman bir miktar belirsizlikle verilir. Önemli olan, kararın hangi varsayımlara dayandığının yazılı olması ve bu varsayımların kimin sorumluluğunda, hangi tarihe kadar doğrulanacağının belirlenmesidir.
Bakım takvimi dönüşüm tarihini belirlemeli mi?
Takvim önemli bir girdidir, ancak tek belirleyici değildir. Dönüşüm tarihi; iş hedefleri, teknik hazırlık, kaynak durumu ve yüksek etkili belirsizliklerin giderilme süresi birlikte değerlendirilerek belirlenir.
Hangi belirsizlik önce ele alınmalı?
Etkisi yüksek ve bir kararı bekleten belirsizlikler önce ele alınır. Giderilmesi kolay olanlar hemen kapatılır; zor olanlar için erken başlanır ve karar sahibine taşınır.
Üçüncü taraf eklentiler neden ayrı ele alınır?
Eklentilerin hedef sürümle uyumluluğu ve destek durumu, onları sağlayan tarafa bağlıdır. Bu bilgi dönüşüm ekibinin kendi analiziyle elde edilemez; eklenti sağlayıcısından doğrulanması gerekir.
Geri dönüş planı her dönüşümde gerekli mi?
Bir biçimde gereklidir. En azından hangi noktada geri dönme kararı verilebileceği, bu kararı kimin vereceği ve hangi ölçütlere bakılacağı geçişten önce yazılı olmalıdır.
İlgili sayfalar ve rehberler
- Özel kod envanterinin değerlendirilmesi: özel kod alanındaki belirsizliklerin giderilmesi
- Entegrasyonlarda hata yönetimi ve güvenli tekrar işleme: arayüz tasarımındaki belirsizlikler
- Clean Core yaklaşımında genişletme kararı: dönüşümde genişletmelerin yeniden değerlendirilmesi
- Entegrasyon yaklaşımı
- Özel kod envanteri ve teknik borç yaklaşımı
- Tüm teknik rehberler
Kaynakça
Metindeki köşeli parantez içindeki numaralar aşağıdaki kaynaklara işaret eder.
- 1
Maintenance 2040 — Innovation Commitment for SAP S/4HANA until 2040 — support.sap.com.
Kaynak tarihi: sayfada yayın tarihi belirtilmemiş; sayfadaki duyuru tarihi 4 Şubat 2020 Son doğrulama: 23.09.2026
- 2
Maintenance Timelines for SAP ERP 6.0 (“ECC”) — community.sap.com, SAP tarafından yazılmış blog.
Kaynak tarihi: ilk yayın 20 Eylül 2022; güncelleme tarihi sayfada belirtilmemiş Son doğrulama: 23.09.2026
- 3
Static Code Checks in the Context of an SAP S/4HANA Migration — help.sap.com, ABAP platform belgeleri.
Kaynak tarihi: belge sürümü 2025 FPS01 (Şubat 2026) Son doğrulama: 23.09.2026
Son doğrulama: 23 Eylül 2026
SAP, ABAP, and SAP S/4HANA are the trademarks or registered trademarks of SAP SE or its affiliates in Germany and in other countries.
Bu içerik Castintech tarafından bağımsız olarak hazırlanmıştır.
Bağımsızlık notu
- Castintech, SAP SE ile ortaklık, yetkilendirme, onay veya sponsorluk ilişkisi iddia etmez.
- SAP ve bu sayfada geçen SAP ürün adları, SAP SE’nin veya iştiraklerinin ticari markalarıdır.
- Castintech’in sunduğu çalışma, bağımsız teknik danışmanlık ve destek kapsamındadır.