SAP proje kurtarma: rotadan çıkmış bir programı kurtarmak

SAP proje kurtarma, rotadan çıkmış bir geçişi veya uygulamayı durdurmak, onunla ilgili gerçekte neyin doğru olduğunu bulmak ve o gerçekten yola çıkarak yeniden planlamak demektir. İşe yarayıp yaramayacağını ilk hafta belirler: program durumunu değerlendirin, tasarımı gözden geçirin ve sistemde gerçekte ne kurulu olduğunu değerlendirin.

Kısa cevap: bu üç kontrol birbiriyle ve planla örtüşüyorsa programın bir kurtarmaya değil, bir itmeye ihtiyacı vardır. Örtüşmüyorsa mevcut plana ne kadar ek efor harcanırsa harcansın sorun çözülmez ve yeni bir baz çizgisiyle resmi bir kurtarmaya ihtiyacınız olur.

Bu yazı o teşhis ve ardından gelenler hakkında. Yolları, süreleri ve son tarihleri anlatan ECC'den S/4HANA'ya geçiş rehberimin bir parçasıdır. Burada soru daha dar: programınız başı dertte, peki şimdi ne olacak?

Geciken programların çoğunun kurtarılmaya ihtiyacı yoktur. Kararların daha hızlı verilmesine, bir anahtar kullanıcının serbest bırakılmasına veya bir tedarikçinin bir tarihe bağlı tutulmasına ihtiyaçları vardır. Bu bir itmedir.

Kurtarma farklıdır. İşaretler ilk haftada yaptığım aynı üç kontrolden gelir ve sinyal basittir: durum, tasarım ve kurulu olan şey birbiriyle veya planla örtüşmez.

Kurtarma sinyali olarak göreceğim bazı kalıplar:

1. Durum yeşil, sistem değil. Raporlar geliştirmenin büyük kısmının bittiğini söylüyor, ama test sistemi temel bir order-to-cash sürecini çalıştıramıyor.
2. Tasarım imzalı, geliştirme onu yok sayıyor. Konfigürasyon onaylı tasarımdan değil, atölye notlarından yapılmış.
3. Planda bir canlıya geçiş tarihi var, kimse oraya giden yolu açıklayamıyor. Testin, veri yüklemelerinin ve cutover provalarının gerçekçi bir yeri yok.
4. Kapsam yalnızca büyüyor. WRICEF listesi (raporlar, arayüzler, dönüşümler, geliştirmeler, formlar ve iş akışları) Explore fazından çok sonra hâlâ artıyor.

Bunlardan herhangi biri bir itmeyle düzeltilebilir. İki veya daha fazlası aynı anda genellikle düzeltilemez.

İlk hafta neyin doğru olduğunu bulmak içindir. Düzeltmek, suçlamak veya yeni bir plan yazmak için değil. Üç şeyi şu sırayla değerlendiririm: durum, tasarım ve sistemde gerçekte ne kurulu olduğu.

Her kontrolün neyi kapsadığı ve bir uyuşmazlığın size ne söylediği şöyle:

Kontrol	Neye bakarım	Hangi soruyu yanıtlar	Diğerleriyle uyuşmazsa
Program durumu	Plan, durum raporları, RAID kaydı, açık değişiklik talepleri, bütçeye karşı harcama	Program kendisi hakkında neye inanıyor?	Raporlama iyimser veya teslimattan kopuk
Tasarım	İş süreci tasarımı, fit-to-standard çıktıları, WRICEF listesi, açık tasarım kararları	İş tarafına ne vaat edildi?	Geliştirme üzerinde anlaşılandan sapmış ya da tasarım hiç bitirilmemiş
Kurulu olan	Geliştirme ve test sistemleri, konfigürasyon, transportlar, özel kod, şimdiye kadarki veri yüklemeleri	Bugün gerçekte ne var?	Sistemde olmayan işler için ilerleme raporlanmış

Çoğu incelemenin atladığı kontrol üçüncüsüdür. Sistem hakkındaki belgeleri okumak değil, sistemin karşısına oturup süreçleri çalıştırmak demektir.

Durum raporları ve tasarım belgeleri iddiadır. Sistem ise kanıttır.

Kontrolleri kim yürütmeli

Durum raporlarını yazan kişiler onları doğrulayan kişiler olmamalıdır. Bu bir suçlama değil. Denetçilerin kendi işlerini denetlememesiyle aynı nedendir.

İlk haftanın sorumluluğunu, sistemlere tam erişimi ve programdaki herkesle konuşma hakkı olan, uygulama iş ortağından bağımsız birine verirdim. Bu mümkün değilse, en azından iş ortağına kurulu sistemi slaytlarda değil, canlı olarak gösterttirin.

2018'de bir havacılık programının kurtarılmasında çalıştım. Modüller kurulmuştu, ama hiçbir şey iş gereksinimlerine göre konfigüre edilmemişti.

İlk haftanın üç kontrolü tam da bu durumu ortaya çıkarmak için var. Kurulu modüller çalışan bir tasarımla aynı şey değildir ve farkı yalnızca sistemin içine bakmak gösterir.

Havayolları bakımı, satın almayı ve finansı birbirine sıkı bağlar; bu yüzden bir alandaki boşluk diğerlerine yayılır. SAP'nin bu sektöre nasıl uyduğunu havacılık için SAP sayfamda anlatıyorum.

Yönettiğim veya kurtardığım 21 SAP programında gördüğüm en büyük hata, uygulamanın başında doğru planlama yapmamaktır. Bir kurtarma çoğu zaman bu eksik planlamanın geç ve baskı altında yapılmasıdır.

İki neden daha tekrar tekrar karşıma çıkıyor:

1. Kapsamı tedarikçi kontrol ediyor. Kapsamı sistem entegratörü yazdığında, entegratörün teslim etmeyi planladığı şeyi tanımlar. Boşluklar sonradan, aynı tedarikçinin fiyatladığı değişiklik talepleri olarak gelir.
2. Özel kod taşıyor. Deneyimime göre özel kod en sık taşan geçiş fazıdır ve aynı zamanda en çok unutulan gizli maliyettir.

Bunun bütçe tarafını, maliyetlerin neden Explore fazında sıçradığı dahil, SAP projelerinin neden bütçeyi aştığını anlatan yazımda ele alıyorum. Burada tekrarlamayacağım.

Zayıf kontrol diğer ortak noktadır. Programın hiçbir zaman haftalık bir takip, eskalasyon ve değişiklik kontrolü ritmi olmadıysa, kurtarmanın bunu kurması gerekir. SAP proje planlama ve kontrol rehberim bu ritmi sahipleriyle birlikte ortaya koyuyor.

Neyin doğru olduğunu bildiğinizde kurtarmanın net bir sırası vardır. Bir adımı atlamak genellikle kurtarmayı iki kez yapmak demektir.

SAP program kurtarma sırası

1. 01

   Teşhis et

   Durum, tasarım ve kurulu olan, birbirine karşı kontrol edilir.

2. 02

   Kapsamı geri al

   Müşterinin sahip olduğu, dondurulmuş ve her değişikliği fiyatlanmış kapsam.

3. 03

   Yeniden baz çizgisi

   Kanıta dayalı tek bir yeni plan, yedek pay sizin tarafınızda.

4. 04

   Fazlara kapı koy

   Kalan her fazın sonunda bir kalite kapısı.

5. 05

   Prova et ve cutover yap

   Bir canlıya geçiş tarihi teyit edilmeden önce tam provalar.

1. Kapsam sahipliğini geri alın

Kimse yeniden planlamadan önce kapsamın sahibinin kim olduğuna karar verin. Cevap hâlâ tedarikçiyse, yeni plan eskisiyle aynı şekilde başarısız olacaktır.

Kapsamı müşteri tarafında yazın, kurulu olanla karşılaştırın ve dondurun. O andan itibaren her değişiklik, sahibi olan fiyatlanmış bir karardır.

2. Kanıta dayanarak bir kez yeniden baz çizgisi çıkarın

Bir kurtarma bir dizi küçük kayma değil, tek bir yeni baz çizgisi alır. Onu eski planın umduğundan değil, sistemin gösterdiğinden kurun.

Önce özel kodu yeniden tahmin edin, çünkü taşmalar en sık oradan gelir. Ardından veriyi; çünkü veri taşıma eforun yüzde 30 ila 40'ıdır ve sorunlu bir programda genellikle geridedir.

Yalnızca adı konmuş risklere karşı serbest bırakılan yüzde 10 ila 20'lik bir yedek payı kendi tarafınızda tutun. Kardeş yazım S/4HANA geçiş maliyeti rakamları neyin belirlediğini açıklıyor.

3. Her fazın sonuna bir kalite kapısı koyun

Başı dertte olan programlar genellikle fazdan faza kanıta değil, tarihlere göre geçmiştir. Bunu düzeltin.

SAP Activate'te Explore fazı fit-to-standard atölyelerini yürütür ve onaylanan delta gereksinimler Realize için ürün birikim listesine (backlog) girer. Program Explore'dan bitmiş bir tasarım olmadan çıktıysa geri dönün ve onu bitirin. SAP Cloud ALM, proje genel bakışında gösterilen kontrol listeli kontrol noktaları olarak kalite kapılarını destekler; böylece kapının bir elektronik tabloda yaşaması gerekmez.

4. Bir tarihe bağlanmadan önce prova yapın

Brownfield dönüşümünde cutover öncesinde üç deneme dönüşümü planlarım. Sorunlu programlar zaman kazanmak için provaları sıklıkla kısaltır; bu da riski canlıya geçiş hafta sonuna taşır.

Gördüğüm cutover kesintileri bir hafta sonundan bir haftaya kadar uzanıyor. Kurtarılan bir program kendi rakamını bir tahminden değil, bir provadan bilmelidir.

5. Gerçekte çalıştığınız son tarihi kontrol edin

Enhancement package 6 ile 8 arasındaki SAP ERP 6.0 için ana bakım 31 Aralık 2027'de sona erer; 2030 sonuna kadar isteğe bağlı uzatılmış bakım iki yüzde puanlık ek ücretle alınabilir (SAP News). Bir ECC geçişini 2027'nin ötesine iten bir kurtarma, uzatılmış bakımı açıkça bütçelemelidir.

2027 tarihinin, provaların desteklemediği bir canlıya geçişi zorlamasına izin vermeyin. Geç bir canlıya geçiş bakım ücretine mal olur. Başarısız bir canlıya geçiş ise çok daha fazlasına.

Bir kurtarma çoğu zaman mevcut sistem entegratörüyle devam edilip edilmeyeceği sorusunu gündeme getirir. Bazen iş ortağını değiştirmek doğrudur. Çoğu zaman asıl sorun programın nasıl kurulduğudur ve yeni bir iş ortağı bunu miras alır.

Karar vermeden önce soracağım sorular şunlar:

1. Kurulu sistemi, imzalı tasarıma karşı, canlı olarak gösterebilir misiniz? Bir demo ortamı değil, slaytlar değil.
2. Hangi WRICEF nesneleri geliştirildi, test edildi ve transport edildi; hangileri yalnızca bitti olarak raporlandı?
3. İşi bitirmek için üst düzey tasarımınız nedir ve bizimkine benzer bir programı kurtardığınız hangi referansları arayabiliriz? Referanslar ve üst düzey tasarım, imzalamadan önce her iş ortağından istediğim iki şeydir.
4. Bizden ihtiyaç duyup alamadığınız ne var? Eksik kararlar ve yarı zamanlı anahtar kullanıcılar çoğu zaman hikâyenin yarısıdır.
5. RISE with SAP müşterileri için: hangi sorunlar iş ortağında değil, SAP'de duruyor ve bunları kim eskale ediyor?

Uyarı işareti, seçim aşamasında beni bir iş ortağından uzaklaştıranla aynıdır: genel geçer yanıtlar. Kurtarma planı herhangi bir şirkete uygulanabilecekse, sizinki için yazılmamıştır. S/4HANA geçiş iş ortağı seçme rehberim seçim tarafını ele alıyor.

Programda kaynak sistemin doğru bir değerlendirmesi hiç yapılmadıysa şimdi yapın. SAP Readiness Check mevcut sisteminizi analiz eder ve SAP, gerçek kullanımın doğru bir resmi için onu üretimde çalıştırmayı önerir. SAP Readiness Check ve geçiş değerlendirmesi yazım, özel nesnelerden başlayarak onun neyi kaçırdığını açıklıyor.

Program direktörünüz ve SAP sorumlunuzla yarım gün ayırın ve sizden üç şeyi yan yana göstermelerini isteyin: en son durum raporu, imzalı tasarım ve tam bir iş sürecini çalıştıran test sistemi. Bu üçü aynı hikâyeyi anlatıyorsa itin. Anlatmıyorsa, bir sonraki yönlendirme komitesinden önce resmi bir kurtarma başlatın.

Rotadan çıkmış bir program hakkında bağımsız bir görüş istiyorsanız, kuruluşlara tam olarak bu tür bir teşhiste yardım ediyorum. Benimle bir görüşme ayarlayabilirsiniz.

SAP proje kurtarma nedir?

SAP proje kurtarma, rotadan çıkmış bir SAP uygulamasını veya geçişini yeniden kontrol altına alma işidir. Program durumunun, tasarımın ve sistemde gerçekte ne kurulu olduğunun teşhisiyle başlar; ardından kapsam sahipliğini geri alır, tek bir yeni baz çizgisi belirler ve kalan fazlara kalite kapıları ekler.

SAP projemin kurtarılmaya ihtiyacı olup olmadığını nasıl anlarım?

Üç şeyi karşılaştırın: durum raporlarının ne söylediği, imzalı tasarımın ne söylediği ve sistemde gerçekte ne kurulu olduğu. Birbirleriyle ve planla örtüşüyorlarsa programın bir itmeye ihtiyacı vardır. Örtüşmüyorlarsa mevcut plana daha fazla efor harcamak sorunu çözmez ve resmi bir kurtarmaya ihtiyacınız olur.

Bir SAP uygulama kurtarmasının ilk haftasında ne olmalı?

Yalnızca teşhis. Program durumunu değerlendirin, tasarımı gözden geçirin ve sistemde gerçekte ne kurulu olduğunu değerlendirin; ideal olarak bunu uygulama iş ortağından bağımsız biri yönetsin. Bu üç kontrol bitmeden yeni planı yazmayın.

Kurtarma sırasında SAP uygulama iş ortağımızı değiştirmeli miyiz?

Otomatik olarak değil. İş ortağından kurulu sistemi imzalı tasarıma karşı göstermesini ve benzer kurtarmalardan referanslarla birlikte işi bitirmek için üst düzey bir tasarım vermesini isteyin.

Yanıtlar genel geçerse bu, değiştirmek için güçlü bir sinyaldir. Asıl sorun kapsam sahipliği veya sizin tarafınızdaki eksik kararlarsa, yeni bir iş ortağı bunu miras alır.

SAP S/4HANA geçişleri neden rotadan çıkar?

Gördüğüm en yaygın kök neden, uygulamanın başında doğru planlama yapmamaktır. Kapsamın kontrolünü tedarikçiye bırakmak bir diğeridir ve özel kod en sık taşan fazdır. Eforun yüzde 30 ila 40'ını oluşturan veri taşıma da genellikle geridedir.

Bir kurtarma ECC geçişimizi 2027 son tarihinin ötesine iter mi?

İtebilir. Enhancement package 6 ile 8 arasındaki SAP ERP 6.0 için ana bakım 31 Aralık 2027'de sona erer ve isteğe bağlı uzatılmış bakım iki puanlık ek ücretle 2030 sonuna kadar sürer. Provalarınızın desteklemediği bir canlıya geçişi zorlamak yerine uzatılmış bakımı bütçeleyin.