SAP proje risk değerlendirmesi: uygulanabilir sürüm

Bir SAP proje risk değerlendirmesi, programı raydan çıkarabilecekleri listeler ve her riski olasılık ile etkiye göre puanlar. Her riske adı konmuş tek bir sahip ve gerçekleşmeden önce kararlaştırılmış bir yanıt verilir; liste her hafta gözden geçirilir. SAP programlarını batıran riskler nadiren sürprizdir: veri taşıma, entegrasyon, kişilerin müsaitliği, kapsam kayması ve benimseme. Bu rehber, klasörde duran bir risk kaydı yerine kararları değiştiren bir risk kaydı isteyen program yöneticilerine ve sponsorlara yönelik. Size puanlanmış bir matris, bir risk kaydı şablonu, çalışılmış örnekler olarak üç kamuya açık başarısızlık ve RISE with SAP ile Clean Core'un eklediği riskleri veriyor. Elinizdeki her riskin karşısına adı konmuş bir sahip koyarak başlayın.

SAP risk değerlendirmelerinin çoğu ilk yönlendirme komitesinden önce hazırlanır, bir kez gözden geçirilir ve bir daha elden geçirilmez. Bu risk yönetimi değil. Bu bir belge.

Erkenden gündeme getirmek fazla rahatsız edici olduğu için göz ardı edilen riskler gördüm. Bu sessizlik neredeyse her zaman sonradan daha pahalıya mal olur. Malzeme Yönetimi'ndeki küçük bir entegrasyon sorunu birdenbire Finans'ı tıkar. Testte iyi görünen bir rapor, bir sistem güncellemesinden sonra bozulur. Bunun birden fazla kez yaşandığını gördüm.

Riskler sürpriz değildi. Belgelenmişlerdi. Kimse harekete geçmedi.

Kapsam. Proje standart modüllerle başlar. Sonra biri “bir rapor daha” ekler, sonra bir pano, sonra birkaç geliştirme. Tehlike, atölyelerde, e-postalarda ve koridor sohbetlerinde gayriresmi biçimde getirilen, proje yöneticisinin yapılandırma bittikten sonra haberdar olduğu kapsam değişiklikleridir. Kapsam kaymasından kaçınma rehberim kontrolleri ele alıyor.

Kaynaklar. Mimar bir üretim sorununa çekilir. Kilit bir geliştirici ayrılır. İş kullanıcıları, günlük işleri durmadığı için test döngülerini kaçırır. Müsaitliği yazılı alın. Sözlü vaatler kadro baskısı altında buharlaşır.

Teknik. Hedef yapıya karşı hiç doğrulanmamış alan eşlemeleri. Birim testini geçen ama gerçek işlem hacminde bozulan arayüzler. Üretim yüküne kadar iyi görünen özel kod. Nereye bakacağınızı biliyorsanız bunlar öngörülebilirdir.

Takvim. Geç kalan bir blueprint testi sıkıştırır, ama canlıya geçiş tarihi sabit kalır. UAT, eğitim ve veri hazırlığı aceleye gelir. Aynı örüntü, bir faz kapısını kaçıran ve sonraki planı kaydırmayan neredeyse her programda görülür.

Benimseme. İnsanlar anlamadıklarını reddeder. Zayıf ya da geç eğitim geçici çözümler üretir, geçici çözümler veriyi bozar ve bir değişim yönetimi başarısızlığı için sistem suçlanır.

Bu vakalar kamuya açık ve iyi belgelenmiş. Örüntüler her ölçekte tekrarlanır.

Lidl: yedi yılda yaklaşık 500 milyon avro

Lidl, eLWIS projesine SAP for Retail üzerinde 2011'de başladı, bazı küçük ülkelerde canlıya geçti ve bildirilen yaklaşık 500 milyon avro maliyetle 2018'de projeden vazgeçti. Yaygın olarak bildirilen nedenlerden biri: Lidl envanteri satın alma fiyatlarıyla değerlerken, SAP'nin standart perakende modeli satış fiyatlarını kullanıyor. Lidl uygulamayı değiştirmek yerine özelleştirdi ve şirket, özgün hedeflerin makul bir çabayla elde edilemeyeceğini söyledi.

Ders: veri modelinizle SAP'nin standardı arasındaki uyumsuzluk bir birinci hafta riskidir, beşinci yılda keşfedilecek bir şey değil.

HP: yaklaşık 400 milyon dolarlık kayıp gelir

HP, 2004'te sunucu işinin bir bölümünü birleşik, SAP tabanlı bir sipariş ve tedarik zinciri sistemine taşıdı. Siparişler eski ön yüz ile SAP arasında düştü ve elle iş gerektirdi; birikmiş iş ikiye katlandı. HP'nin CEO'su, sorunların sunucu ve depolama grubuna yaklaşık 400 milyon dolar gelire ve 275 milyon dolar faaliyet kârına mal olduğunu, 120 milyon dolarlık bir birikmiş sipariş bıraktığını söyledi. HP'nin CIO'su sonradan ekibin üç haftalık aksama planladığını ve dört ila altı hafta için yedek planı olması gerektiğini söyledi.

Ders: yedek planı ortalama bir cutover'a göre değil, kötü bir cutover'a göre boyutlandırın ve geçişten önce envanter ya da kanal tamponları oluşturun.

Nike: 100 milyon doların üzerinde kayıp satış

Nike, 2000'de SAP ERP programından önce i2 talep planlama yazılımını canlıya aldı. Yazılım, Nike'ın eski sistemleriyle çalışması için yoğun biçimde özelleştirilmişti, yavaş çalıştı ve ürün hacmi altında çöktü. Bazı ayakkabılardan çok fazla, bazılarından çok az sipariş verdi. Nike 100 milyon doların üzerinde satış kaybetti ve hisse senedi yaklaşık %20 düştü. Nike sonradan kısa ve orta vadeli planlamayı SAP'ye taşıdı.

Ders: bir entegrasyonun, gerçek verilerle üretim hacminde çalışana kadar çalıştığını asla varsaymayın.

Varsayımlara dayalı bir değerlendirme hiç olmamasından kötüdür, çünkü yanlış bir güven yaratır. Altı girdi önemlidir:

1. Kapsam belgeleri: proje başlatma belgesi, onaylı kapsam ve imzalı gereksinimler. Yoksa kapsam riski zaten yüksektir.
2. Kaynak taahhütleri: bölüm başkanlarından yazılı taahhütler, kritik roller için bir yetkinlik matrisi ve her kilit pozisyon için adı konmuş bir yedek.
3. Bütçe ve takvim: yedek ödenekli onaylı bütçe ve benzer programlara karşı kontrol edilmiş bir takvim. Tam bir kullanıma alma için altı ay ve asgari finansman, şimdi dile getirilmesi gereken bir risktir.
4. Tedarikçi taahhütleri: hizmet seviyeleri ve cezaları içeren sözleşmeler. RISE'da SAP'nin sorumlulukları ve eskalasyon yolu.
5. Teknik ortam: eski sistem uyumluluğu, veri taşıma karmaşıklığı, dağıtım modeli ve her özel iş için bir Clean Core planı.
6. Geçmiş proje kayıtları: önceki SAP ya da ERP programlarından risk kayıtları, sorun günlükleri ve sonradan değerlendirme (post-mortem) raporları. Risklerin çoğu yeni değildir.

Her riski olasılık ve etki üzerinden 1 ile 5 arasında puanlayın ve çarpın. Aşağıdaki örnek bir S/4HANA programı için tipik bir başlangıç noktasıdır; sizin puanlarınız farklı olacaktır.

Risk	Olasılık (1-5)	Etki (1-5)	Puan	Öncelik
Veri taşıma hatası	4	5	20	Yüksek
Entegrasyon gecikmeleri	4	4	16	Yüksek
Kaynak kısıtları	4	4	16	Yüksek
Bütçe aşımı	3	5	15	Orta
Çekirdekteki özel kodun yükseltmeleri engellemesi	3	5	15	Orta
Kapsam kayması	4	3	12	Orta
Test kapsamı boşlukları	3	4	12	Orta
Yoğun yük altında performans	3	4	12	Orta
Uyumluluk boşlukları	2	5	10	Orta
SAP'ye eskalasyon yolunun olmaması (RISE)	2	5	10	Orta
Düşük kullanıcı benimsemesi	3	3	9	Orta
Abonelik ya da lisans maliyeti riski	2	4	8	Orta
KPI'ların izlenmemesi	3	2	6	Düşük

16 ve üzeri puanlar adı konmuş bir sahip ve hemen eylem gerektirir. 8 ile 15 arasındaki puanlar, tanımlı bir eskalasyon tetikleyicisiyle izleme gerektirir. 8'in altındakiler kayıtta kalsın, ama öncelikli zaman harcamayın. Puanlar bir başlangıç noktasıdır, hüküm değil: 10 puanlı bir uyumluluk boşluğu, düzenlemeye tabi bir sektörde 25'e çıkabilir.

Tek başına bir puan hiçbir şeyi değiştirmez. Her risk için bu alanlar doldurulmuş olmalıdır.

Alan	Ne yazılmalı	Örnek
Risk	Olay, tek cümleyle	Tedarikçi ana verisi, 2. mock yüklemesinden önce temizlenmedi
Sahip	Adı konmuş tek kişi	Borç hesapları (AP) lideri
Puan	Olasılık × etki	4 × 5 = 20
Tetikleyici	Harekete geçtiğiniz ölçülebilir nokta	1. mock çıktısında yinelenen kayıt oranı %5'in üzerinde
Yanıt	Kaçın, azalt, aktar ya da kabul et; eylemiyle birlikte	Azalt: üç hafta boyunca temizlik için iki AP analisti
Sonraki gözden geçirme	Tarih	Gelecek Pazartesi'nin risk toplantısı
Durum	Açık, eylemde, kapalı	Eylemde

Mümkün olduğunda maliyeti somut terimlerle yazın. “Yüksek risk” muğlaktır. “Bir haftalık UAT gecikmesi ekip zamanında yaklaşık altı haneli bir tutara mal olur ve canlıya geçişi üç hafta öteleyebilir” dikkat çeker.

Özel kod başlı başına bir risk kategorisidir. S/4HANA Cloud Public Edition'da çekirdekte özel kod mümkün değildir. Uzantılar SAP BTP, yayımlanmış API'ler ya da key-user araçları üzerinden gider. Private cloud ve on-premise'ta çekirdeği hâlâ değiştirebilirsiniz ve bunu yapmaya alışkın ortaklar da yapacaktır. Bu teknik borç ilk büyük yükseltmede ortaya çıkar. Belirlenen özelleştirmelerin kaçının üzerinde uzlaşılmış bir Clean Core yaklaşımı olduğunu izleyin, ortağın BTP uzantı deneyimini kontrol edin ve Explore bitmeden bir inceleme forumu kurun.

RISE, erişilebilirliğin sahibini değiştirir. Altyapıyı SAP işlettiği için risk, “erişilebilirliğin sahibi bizim ekibimiz” durumundan “sahibi SAP ve bir şey bozulduğunda ona hızlı bir giriş yoluna ihtiyacımız var” durumuna kayar. SAP'nin adı konmuş iletişim kişilerini, eskalasyon yolunu ve hizmet seviyelerini, ayrıca canlıya geçişten önce kararlaştırılmış bir olay planını kaydedin. Bunlar olmadan, SAP'ye gitmesi gereken sorunlar proje ekibinin içinde çok uzun süre bekler.

Yapay zeka evrak işine yardım eder, muhakemeye değil. SAP Cloud ALM'deki Joule tabanlı asistanlar ve Microsoft Copilot gibi araçlar, durum raporlarından, hata günlüklerinden ve toplantı tutanaklarından risk kaydı girdileri ve yönlendirme komitesi dosyaları taslağı hazırlayabilir. Bu, kaynak verisi temiz programlarda kayıt bakımını hızlandırır. Verinin içinde zaten görünen riskleri bulur. Hangi risklerin eyleme değer olduğuna karar vermez, sahiplerini harekete geçirmez, yönetimin görmezden gelmeyi tercih edeceği riskleri eskale etmez.

1. Riskleri beş kategorinin tümünde belirleyin. BT, iş birimi ve tedarikçilerle atölyeler yapın; her biri farklı riskler görür. RISE'da en az birine SAP'nin iletişim kişilerini dahil edin. Ekiplerin genellikle gözden kaçırdığı riskler: BT ile iş biriminin farklı şeyler beklemesi, kötü tanımlanmış dış entegrasyonlar, müsait olmayan UAT sahipleri ve gayriresmi kapsam değişiklikleri.
2. Her riski puanlayın, olasılık ve etki üzerinden, mümkün olduğunda gerçek rakamlarla.
3. Her riske tek bir sahip atayın. Bir kişi, bir ekip değil. Sahip yoksa takip yok, çözüm yok.
4. Yanıtı risk gerçekleşmeden önce tanımlayın. Kaçın, azalt, aktar ya da kabul et. “İzle ve yanıt ver” bir plan değildir. Ertelenmiş bir karardır.
5. Haftalık gözden geçirin. Açık riskleri kontrol edin, yenilerini ekleyin, koşullar değiştiğinde yeniden puanlayın ve tetikleyicisine yaklaşan her şeyi eskale edin. En önemli riskleri yönlendirme komitesine bir renk yerine önerilen bir kararla getirin.

1. 01BelirleBeş kategorinin tümü
2. 02PuanlaOlasılık × etki, 1 ile 5
3. 03Sahip ataBir kişi, bir ekip değil
4. 04Yanıtı tanımlaKaçın, azalt, aktar ya da kabul et
5. 05Haftalık gözden geçirYeniden puanla, tetikleyiciye yaklaşanı eskale et

16 ve üzeri: adı konmuş bir sahip ve bu hafta eylem

Bir SAP projesinde risk değerlendirmesi nedir?

Neyin ters gidebileceğini belirleme, her riski olasılık ve etkiyle puanlama, her birine bir sahip verme ve gerçekleşmeden önce bir yanıt üzerinde anlaşma sürecidir. SAP programları aynı anda birkaç modül, entegrasyon, bir veri taşıma, bir değişim programı ve sabit bir canlıya geçiş yürütür; bu nedenle gayriresmi risk yönetimi ayakta kalmaz. Sahipleri olan kısa bir gerçek risk listesi, kimsenin okumadığı uzun bir belgeden iyidir.

Bir SAP projesi için risk matrisi nasıl oluşturulur?

Riskleri kapsam, kaynaklar, teknik, takvim ve benimseme boyunca, ayrıca RISE'da Clean Core ve SAP eskalasyonu için listeleyin. Her birini olasılık ve etki üzerinden 1 ile 5 arasında puanlayın ve çarpın. 16 ve üzerini yüksek, 8 ile 15 arasını orta, 8'in altını düşük sayın. Her orta ve yüksek riske bir sahip ve ölçülebilir bir tetikleyici verin; örneğin “UAT tamamlanması 16. haftada %80'in altındaysa canlıya geçiş tarihi incelemeye alınır”. Haftalık ve her faz kapısında yeniden puanlayın.

SAP uygulamalarındaki en yaygın riskler nelerdir?

Veri taşıma hatası, çünkü eski veri neredeyse her zaman tahmin edilenden daha dağınıktır. Entegrasyon gecikmeleri, özellikle belgelenmemiş eski arayüzlerde ve üçüncü taraf tedarikçilerde. Testi ve eğitimi sıkıştıran kapsam kayması. Kilit kişilerin başka yere çekilmesi ya da kullanıcıların ay sonunda UAT sırasında müsait olmaması gibi kaynak kısıtları. İşi simüle etmek yerine ekranları gösteren eğitimden kaynaklanan düşük benimseme. RISE'da çekirdekte özel kodu ve SAP'ye eskalasyon yolunun olmamasını ekleyin.

Bir SAP projesinde risk değerlendirmesi ne zaman yapılmalı?

Proje başlamadan önce, veri modeli uyumsuzlukları ya da gerçekçi olmayan takvimler gibi yapısal risklerin düzeltilmesi en ucuz olduğunda. Her SAP Activate faz kapısından önce, çünkü her faz risk profilini değiştirir. Kapsam, bütçe ya da kaynaklar değiştiğinde. Ve bir risk soruna dönüştüğünde, başka neyi etkilediğini kontrol etmek için. Bunların arasında haftalık gözden geçirin.

Bir SAP programında riskler kime ait olmalı?

Onlara karşı harekete geçebilen kişiye. Veri lideri veri taşıma riskine, teknik mimar entegrasyon riskine, değişim lideri benimseme riskine, çözüm mimarı da Clean Core riskine sahip olur. RISE'da CIO ya da program direktörü, SAP'ye eskalasyon yoluna sahip olur. Program yöneticisi kaydın sağlığını izler ama her riske sahip değildir.

ERP risk değerlendirmesi atlandığında ne olur?

Büyük ölçekte, SAP perakende projesinden yaklaşık 500 milyon avro sonra 2018'de vazgeçen Lidl gibi vakalar çıkar. Ya da 2004'teki SAP sipariş sistemi geçişi sunucu grubuna yaklaşık 400 milyon dolar gelire mal olan HP. Daha küçük ölçekte mekanizma aynıdır: geç keşfedilen veri modeli uyumsuzlukları, üretim hacminde başarısız olan entegrasyonlar ve zayıf eğitimden doğan benimseme başarısızlıkları. Riskler sorun olmadan önce tanımlanabilirdi.