SAP AMS sözleşme modelleri: ticket bazlı mı, kapasite bazlı mı?

Model seçimi neden fiyattan önce gelir?

SAP AMS tekliflerini karşılaştırırken çoğu şirket önce aylık tutara bakar. Oysa tutarı belirleyen şey sözleşme modelidir: aynı kapsam, ticket bazlı bir kurguda dalgalı, kapasite bazlı bir kurguda sabit bir maliyet üretir. Modeli işletmenizin talep profiline uydurmadığınız sürece fiyat pazarlığı yalnızca riski taraflar arasında kaydırır.

Talep profilini üç veriyle çıkarabilirsiniz: son on iki ayın aylık ticket adedi, bu ticket'ların öncelik dağılımı ve küçük değişiklik taleplerinin (change request) payı. Bu üç sayı olmadan yapılan her model tercihi tahmindir.

Ticket bazlı model

Ticket bazlı modelde sağlayıcı, kapatılan olay başına ya da önceden satın alınmış bir ticket paketi üzerinden ücretlendirir. Talep hacmi düşük ve öngörülebilir olan, custom code'u sınırlı sistemlerde en verimli modeldir.

• Avantaj: kullanılmayan kapasite için ödeme yapmazsınız; maliyet doğrudan tüketimle ilişkilidir.
• Risk: sınıflandırma tartışması. Bir talebin olay mı yoksa change request mi olduğu net tanımlanmazsa her ay fatura tartışması çıkar.
• Gerekli madde: öncelik sınıflarının, ticket kapanış kriterlerinin ve paket aşımında uygulanacak birim fiyatın sözleşmede yazılı olması.
• Tipik uyum: ayda 40 ticket'ın altında, kararlı bir üretim sistemi.

Kapasite bazlı model

Kapasite bazlı modelde belirli bir uzman kapasitesini (örneğin ayda 30 gün, tanımlı modül karışımıyla) sabit ücretle satın alırsınız. Sağlayıcı bu kapasiteyi ticket'lar, küçük geliştirmeler ve önleyici bakım arasında planlar.

• Avantaj: bütçe sabittir ve kapasite yalnızca hata düzeltmeye değil, iyileştirmeye de harcanabilir.
• Risk: kapasite fiilen kullanılmazsa maliyet boşa gider; bu nedenle aylık kullanım raporlaması şarttır.
• Gerekli madde: kullanılmayan kapasitenin bir sonraki aya devri, kapsam dışı işler ve kapasite artırım koşulları.
• Tipik uyum: yoğun custom code, sürekli değişiklik talebi ve devam eden roll-out'lar.

Hibrit model: pratikte en sık kurgulanan yapı

Sahada en çok işleyen kurgu genellikle karma bir yapıdır: kritik üretim desteği için SLA'lı sabit bir taban ücret, bunun üzerine değişiklik talepleri için esnek bir gün havuzu. Taban ücret operasyonel güvenliği, havuz ise geliştirme esnekliğini finanse eder.

Hibrit modelin başarısı tek bir ayrıma bağlıdır: neyin taban kapsamda, neyin havuzdan karşılanacağı. Bu ayrım örneklerle yazılmalıdır — 'arayüz hatasının analizi taban kapsamdadır, yeni bir alanın eklenmesi havuzdan düşer' gibi.

Her modelde bulunması gereken SLA maddeleri

Model ne olursa olsun, sözleşmenin servis seviyesi bölümü aynı temel maddeleri içermelidir. Eksik bırakılan her madde, ilk kritik kesintide pazarlık konusu haline gelir.

• Öncelik sınıfı tanımları ve her sınıf için tepki ile çözüm hedefleri.
• Servis saatleri, nöbet kapsamı ve tatil günlerinin nasıl ele alınacağı.
• Ölçüm yöntemi: sürenin hangi anda başlayıp hangi anda durduğu (müşteri beklemesi dahil mi).
• Aylık raporlama içeriği: hacim, SLA uyumu, tekrar eden hatalar, iyileştirme önerileri.
• Çıkış maddesi: sözleşme sonunda bilgi devri, dokümantasyon ve geçiş desteği.

Karar kılavuzu

Kısa bir kural: hacminiz düşük ve öngörülebilirse ticket bazlı, sürekli geliştirme ihtiyacınız varsa kapasite bazlı, ikisi bir arada ise hibrit model doğru olandır. Modeli ilk yıl sonunda gerçek verilerle yeniden değerlendirmek üzere sözleşmeye bir gözden geçirme maddesi koyun.

OXORY tarafında AMS kurulumları Almanya merkezli hizmet yönetimi ile nearshore teslimat kapasitesini birleştirir; model seçimi, mevcut ticket geçmişinizin analiziyle başlar.

Sık sorulan sorular

Ticket bazlı AMS sözleşmesi ne zaman mantıklıdır?

Aylık talep hacmi düşük ve kararlıysa, custom code sınırlıysa ve büyük bir roll-out planlanmıyorsa ticket bazlı model genellikle en düşük toplam maliyeti verir.

Kapasite bazlı modelde kullanılmayan gün ne olur?

Sözleşmede devir maddesi varsa bir sonraki aya aktarılır. Bu madde yoksa kapasite ay sonunda düşer; bu nedenle devir ve azami birikim sınırı yazılı olmalıdır.

SAP AMS fiyatlandırması neye göre değişir?

Kapsanan modüller, servis saatleri, öncelik sınıflarının sıkılığı, custom code hacmi ve teslimat lokasyonu fiyatı belirleyen ana kalemlerdir.

Olay ile değişiklik talebi arasındaki sınır nasıl çizilir?

Olay, çalışan bir fonksiyonun bozulmasıdır; değişiklik talebi ise yeni bir davranış ister. Sınır, sözleşmeye somut örneklerle yazıldığında fatura tartışması ortadan kalkar.

Sözleşme süresi ne kadar olmalı?

Tipik süre 24 aydır; ilk 12 ayın sonunda model ve hacim için bir gözden geçirme maddesi koymak, kurulumu gerçek verilere göre düzeltmenizi sağlar.

Mevcut sağlayıcıdan geçiş nasıl yapılır?

Sistem envanteri, custom code taraması, kritik süreçlerin belgelenmesi ve gölge işletim ile dört-sekiz haftalık bir devir planı uygulanır.