SAP proje planlama ve kontrolü: projeleri yolunda tutun

Çoğu SAP programının bir planı var. Kontrolü olan çok daha az. Planlama kapsamı, takvimi, bütçeyi ve riskleri belirler. Kontrol ise ilerlemeyi plana karşı izleme, bağımlılıkları yönetme, erkenden eskalasyon yapma ve her değişikliği onaylanmadan önce değerlendirme işidir ve her hafta yapılır. Bu rehber, SAP programı kayan ya da kaymasını önlemek isteyen program direktörleri, PMO'lar ve sponsorlar için. Kontrolün neye benzediğini, o olmadığında ne olduğunu gösteren üç kamuya açık başarısızlığı ve bu hafta benimseyebileceğiniz, sahipleri belli bir haftalık kontrol ritmini kapsıyor.

İşe yeni başladığım dönemde, kâğıt üzerinde harika görünen bir SAP programında çalıştım. Takvimler, risk kayıtları, değişiklik günlükleri, beklediğiniz her şey vardı. Kimse onu izlemiyordu. Yönlendirme komitesi nadiren toplanıyordu. Finans veri geçişini bekliyordu. IT başlamamıştı. Kimse bağımlılıkları takip etmiyordu. Herkes işleri yolunda tutanın bir başkası olduğunu varsayıyordu.

Altıncı ayda projenin yarısı takvimin gerisindeydi ve kendi hatalarımızın peşinde koşuyorduk. En kötüsü, kimsenin bunun geldiğini görmemesiydi.

Bu bir planlama sorunu değildi. Bir kontrol sorunuydu. Gerçek bir kaynak tahsisi, düzgün bir risk azaltma ve eskalasyon yolu yoktu. Plan bir kez üretilmiş, sonra toplantılar uğruna terk edilmişti.

Planlama; kapsamı, takvimi, bütçeyi, kaynakları, risk kaydını ve kilometre taşı taahhütlerini kapsar. Çoğu ekip bunu üretir. Soru, bunu haftadan haftaya kullanıp kullanmadıklarıdır.

Kontrol; gerçek ilerlemeyi plana karşı izlemeyi, sapmaları erkenden ortaya çıkarmayı, bağımlılıkları yönetmeyi, işler kaydığında eskalasyon yapmayı ve kapsam ya da takvim resmen değiştiğinde baseline'ı yeniden belirlemeyi kapsar. Çoğu ekip bunu kötü yapar.

1. 01İlerlemeyi izleİş paketi bazında plana karşı gerçekleşen
2. 02Sapmaları ortaya çıkarÜç gün geciken her görev
3. 03Bağımlılıkları kontrol etBu kayarsa kimin işi tıkanır
4. 04Eskalasyon yapÖnceden kararlaştırılan bir yolla
5. 05Değişiklikleri değerlendirÖnce zaman, maliyet ve kaynaklar
6. 06Baseline'ı yeniden belirleYalnızca resmi bir değişiklikten sonra

Her hafta, adı belli sahiplerle

Kontrol olmadığında bozulanlar şunlar:

Kontrol olmadığında ne bozulur	Neden olur
Teslim tarihleri sessizce kayar	Kilometre taşı gözden geçirmeleri arasında kimse kontrol etmez
Varsayımlar doğrulanmaz	Her ekip bağımlılığı diğerinin ele alacağını bekler
Kapsam gayriresmî olarak genişler	Değişiklikler, etki değerlendirmesi yapılmadan toplantılarda onaylanır
Riskler gerçekleşene kadar göz ardı edilir	Risk kaydı haftalık yerine üç ayda bir güncellenir
Maliyetler bütçeyi aşar	Efor zaman kayıtlarında durur ama iş paketlerine eşlenmez
Ekipler iletişimi keser	Durum toplantıları, eylemsiz güncellemelere dönüşür

Bunlar kamuya açık vakalar, müşteri hikâyeleri değil. Kök nedenleri, danışmanlık işimde tekrar tekrar gördüklerimdir.

Lidl: yaklaşık yedi yıl ve tahmini 500 milyon avro, sonra durduruldu

Lidl, eLWIS projesine SAP Retail üzerinde 2011'de başladı. Envanter değerleme uygulaması SAP'nin standart modelinden farklıydı ve Lidl, uygulamayı değil yazılımı uyarlamayı seçti. 2018'e gelindiğinde sistem Avusturya, Kuzey İrlanda ve ABD'de canlıydı, ancak yönetim kurulu özgün hedeflerin makul maliyetle ulaşılabilir olmadığı sonucuna vardı. Lidl projeyi durdurdu ve kendi iç sistemini geliştirmeye geri döndü. Ticari basın harcamayı yaklaşık 500 milyon avro olarak tahmin etti ve BT yönetim kurulu üyesi 2017'de ayrılmıştı. Karar Temmuz 2018'de Heise tarafından haberleştirildi. Ders: eski bir uygulamayı korumak için yıllarca özelleştirme yapmak bir yazılım başarısızlığı değil, bir kontrol başarısızlığıdır.

Hershey: Cadılar Bayramı için yaklaşık 100 milyon dolarlık sipariş teslim edilemedi

Hershey'nin yeni SAP, Siebel ve Manugistics sistemi, şekerleme için sakin bir ay olan Nisan 1999'da canlıya geçecek şekilde planlanmıştı. Üç ay kaydı ve Cadılar Bayramı siparişleri gelmeye başlarken Temmuz'da canlıya geçti. Siparişler sistemden depolara ulaşamadı. CEO analistlere, sorunların Hershey'nin Cadılar Bayramı için yaklaşık 100 milyon dolarlık ürünü teslim etmesini engelleyeceğini söyledi ve üçüncü çeyrek satışları yüzde 12,4 düştü. CIO dergisinin anlatımı, gerçek başarısızlığı zamanlamaya bağlıyor. Yoğun sezonu koruyan bir takvim kontrolü, farklı bir canlıya geçiş tarihi dayatırdı.

Revlon: aksayan bir tesis ve kontrollerde önemli zayıflık

Revlon, SAP'yi en büyük üretim tesisi olan Oxford, Kuzey Karolina fabrikasında Şubat 2018'de devreye aldı. Hizmet aksamaları üretimi ve büyük ABD perakendecilerine yapılan sevkiyatları vurdu. Mart 2019'da Revlon, devreye almayla bağlantılı olarak iç kontrolde önemli bir zayıflık açıkladı; etkin bir sürekli risk değerlendirmesinin bulunmadığını ve etkilenen operasyonlarda yeterli sayıda eğitimli personel olmadığını belirtti. Yatırımcılar dava açtı; TechTarget davayı haberleştirdi ve dava yaklaşık 64 milyon dolarlık sevkiyatın yerine getirilemediğini iddia ediyordu.

Bunların hiçbiri SAP yanlış seçim olduğu için başarısız olmadı. Onlarca yıldır var olan planlama ve kontrol temellerinde başarısız oldular.

İş kırılım yapısı

İş kırılım yapısı (WBS), toplam kapsamı net sahipleri olan teslimatlara böler. Onsuz iş, geciktiği ana kadar görünmez. Bir SAP programında süreç tasarımını, yapılandırmayı, veri geçişini, entegrasyonu, testi, eğitimi ve cutover'ı kapsar; her biri sahibi ve teslim tarihi olan görevlere kadar kırılır.

Değer belgede değil. Neyin yapılması gerektiği, kimin yapacağı ve neye bağlı olduğu konusundaki konuşmayı zorunlu kılıyor. Projeleri öldüren şey bağımlılıklardır. Veri geçişindeki bir gecikme entegrasyon testini, o da UAT'yi bloke eder, o da cutover penceresini sıkıştırır. WBS bu zinciri görünür kılar.

Takvim yönetimi

Takvimler öngörülebilir nedenlerle başarısız olur. İnsanlar başka işlere çekilir. Tahminler yanlıştı. Kararlar planlanandan uzun sürer. Tampon payını ilk günden ekleyin: her yere yayılmış bir dolgu olarak değil, en çok ihtiyaç duyması muhtemel görevlerin yanında açık bir tampon olarak.

Takvimi her hafta izleyin. Dördüncü haftadaki bir haftalık gecikme bir konuşmadır. On altıncı haftadaki dört haftalık gecikme bir krizdir. Aynı sorun, düzeltme maliyeti çok farklı.

Canlıya geçiş zamanlamasını ayrı bir karar olarak ele alın. Yoğun bir iş döneminin içine asla canlıya geçmeyin. Hershey'nin dersi her şirket için geçerli.

Bütçe kontrolü

Bütçeler üç nedenle bozulur: yönetilmeyen kapsam değişiklikleri, yetersiz tahmin edilmiş veri geçişi ve erken tahminlerin üzerine çıkan hypercare maliyetleri. Gerçekleşen harcamayı ilk haftadan itibaren plana karşı izleyin. Bir sapma yönlendirme komitesine ulaştığında, aksama olmadan düzeltmek için genellikle çok geçtir.

Değişiklik kontrolü ana bütçe korumasıdır. Her kapsam değişikliği, onaydan önce zaman, maliyet ve kaynaklar üzerinde bir etki değerlendirmesinden geçer. Değerlendirme onaydan sonra geliyorsa, değişiklik bütçeyi atlamıştır. SAP uygulamalarında kapsam kaymasından kaçınma rehberim, değişiklik kurulunu daha derinlemesine ele alıyor.

Risk yönetimi

Üç ayda bir tutulan bir risk kaydı tiyatrodur. Riskler haftalık gözden geçirme, adı belli sahipler ve müdahale planları ister. Her SAP programında şunları adlandırın: geç bulunan veri kalitesi, entegrasyon gecikmeleri, kaynak erişilebilirliğindeki boşluklar, cutover penceresinin sıkışması ve zayıf kullanıcı benimsemesi.

Bir müşteri, veri geçişi tedarikçisi teslim tarihini art arda kaçırınca üç ay kaybetti. Bütçeyi patlatmadan tedarikçiyi değiştirmek için çok geç olana kadar “sadece iki hafta daha” lafını duyup durduk. Sahibi ve tetikleme tarihi olan bir risk, bu kararı aylar önce zorlardı. SAP risk değerlendirme matrisim, bu riskleri puanlamak ve sahiplendirmek için bir şablon veriyor.

İletişim ve eskalasyon

Yöneticilerin manşetlere ihtiyacı var. Teslimat ekiplerinin ayrıntılara. Proje yöneticilerinin sapma verisine. Herkes için tek bir güncelleme kimseye yaramaz.

Eskalasyon yollarını kriz öncesinde belgeleyin ve prova edin. Bir SAP uygulamasında IT, finansın yapılandırmayı gözden geçirdiğini, finans da IT'nin geçirdiğini varsaydı. Canlıya geçişe üç ay kalana ve kritik onaylar eksik kalana kadar kimse bunu dile getirmedi; çözüm son dakika telaşı, ek maliyet ve ertelenen bir devreye alma oldu. Başka bir şirket bunu doğru yaptı: raporlama yapılandırılmıştı ve eylemlere bağlanmıştı; bu yüzden bir sorun çıktığında herkes sahibinin kim olduğunu, etkisinin ne olduğunu ve nasıl çözüleceğini biliyordu.

Kapsam, eskalasyonun karşılığını verdiği yerdir. Basit bir rezervasyon yükseltmesiyle başlayan bir havayoluyla çalıştım. Altı ay sonra sadakat değişiklikleri, mürettebat planlaması ve finans modülleri eklenmişti. Hiçbiri acil değildi. Kimse hayır demedi. Takvim ikiye katlandı ve maliyetler yüzde 70 arttı.

On-premise döneminin el kitabı, RISE with SAP'ye değişmeden taşınmıyor. Üç şey farklı.

RISE, kime eskalasyon yaptığınızı değiştirir

RISE with SAP altında SAP, altyapıyı ve teknik operasyonları yürütür ve benimsemeyi izleyen bir müşteri başarı ekibi sağlar. Kontrol yapınızın onları da içermesi gerekir. Platform sorunları için (sistem performansı, hyperscaler bölgesi, SAP hizmet seviyeleri) program yöneticisinin SAP'ye, uygulama iş ortağı üzerinden geçmeyen, belgelenmiş bir eskalasyon yoluna ihtiyacı var. İhtiyaç duymadan önce yazıya dökün.

Clean core, kapsam kontrolüne teknik bir destek verir

Artık her boşluk için bir karar gerekiyor: yapılandır, yayımlanmış API'ler üzerinden genişlet (ABAP Cloud ile on-stack ya da SAP BTP üzerinde side-by-side) ya da reddet. S/4HANA Cloud Public Edition'da çekirdeği değiştirmek bir seçenek değil. Private edition'da ve on-premise'te mümkün, ama SAP'nin clean core rehberi bunu son çare sayıyor, çünkü her modifikasyon yükseltme işi ekler.

Bu, kapsam kontrolüne yardım ediyor. “Standart order-to-cash sürecini biraz ayarlayalım” talebi, gelişigüzel bir yapılandırma sohbeti olmaktan çıkıp tasarım, geliştirme ve test eforu olan bir uzantıya dönüşüyor. Yönlendirme komitesinin altına, onaylama ya da reddetme yetkisi olan tek bir mimarın bulunduğu küçük bir uzantı gözden geçirme forumu koyun. Onsuz her özelleştirme tartışması yönlendirme komitesinde biter.

Yapay zeka raporları hazırlar, kararları insanlar verir

Yapay zeka artık kontrolün evrak işine yardım ediyor. SAP'nin uygulama yaşam döngüsü aracı SAP Cloud ALM, proje görevlerini, gereksinimleri ve test durumunu tutar ve atölye transkriptlerinden gereksinim taslakları üretebilir. Microsoft Copilot, panolardan ve durum raporlarından yönlendirme komitesi paketleri için sapma özetleri hazırlar. Power BI ya da SAP Analytics Cloud'daki anomali tespiti, olağan örüntüsünden sapan KPI'ları işaretler. Bu, kaynak kullanımı, değişiklik talebi hacmi ve destek talepleri için yararlıdır; doğal olarak dalgalanan metrikler için daha az.

Yapay zekanın yapmadığı şey harekete geçmek. Bir pano takvim kaymasını altı hafta boyunca kırmızı gösterebilir. Yönlendirme komitesi hiçbir şey yapmazsa kayma sürer.

Bu, aktif teslimattaki bir program için asgari ritimdir. Herhangi bir satır eksikse, her şeyden önce onu ekleyin.

Kontrol	Asgari uygulama	Sahibi	Sıklık
İş kırılım yapısı	Her görevin bir sahibi, bir teslim tarihi ve bağımlılıkları var	PMO lideri	Haftalık güncellenir
Takvim gözden geçirmesi	Üç günden fazla geciken her görevi işaretleyin; kritik yolu kontrol edin	Program yöneticisi	Haftalık
Bütçe takibi	İş paketi bazında plana karşı gerçekleşen	Program finans lideri	Haftalık, aylık raporlanır
Risk gözden geçirmesi	Her aktif riskin bir sahibi, bir tetikleyicisi ve bir müdahalesi var	Çalışma kolu liderleri	Haftalık
Değişiklik kontrolü	Onaydan önce zaman, maliyet ve kaynaklar üzerinde etki değerlendirmesi	Değişiklik kurulu başkanı	Haftalık ya da talepler geldikçe
Uzantı gözden geçirmesi (RISE ve GROW)	Her boşluk için yapılandır, genişlet ya da reddet kararı	Çözüm mimarı	İki haftada bir
Yönlendirme komitesi	Durum değil, kararlar; belgeler önceden gönderilir	Yönetici sponsor	İki haftada bir; cutover ve hypercare'de haftalık

Planlama ve kontrol çoğunlukla yöntem yanlış olduğu için değil, disiplin dördüncü ayda bırakıldığı için başarısız olur. Ritmi, ekibin on dördüncü ayda hâlâ yürütecek kadar küçük tutun. Yönlendirme komitesinin kendisi için etkili bir SAP yönlendirme komitesi oluşturma rehberime bakın.

Proje planlama ile proje kontrolü arasındaki fark nedir?

Planlama yol haritasını üretir: kapsam, takvim, bütçe, kaynaklar ve riskler. Başlangıçta yönü belirler.

Kontrol, ilerlemeyi plana karşı izlemenin, sapmaları ortaya çıkarmanın, bağımlılıkları yönetmenin ve resmi değişiklikler olduğunda baseline'ı yeniden belirlemenin süregelen işidir. Programın ömrü boyunca her hafta olur.

Çoğu SAP programı planlamaya yoğun yatırım yapar, kontrole çok az. Sapma yönlendirme komitesinde göründüğünde, haftalar ya da aylar süren toparlanma maliyeti çoktan birikmiştir.

SAP projeleri proje planına rağmen neden başarısız olur?

Çünkü planı kimse işletmiyor. Bağımlılıklar izlenmiyor, bu yüzden bir çalışma kolunun gecikmesi sessizce bir diğerini bloke ediyor. Risk kayıtları üç ayda bir güncelleniyor. Kapsam değişiklikleri gayriresmî olarak onaylanıyor. Yönlendirme komitesi aylık toplanıyor ve sahada olanları gizleyen kilometre taşı özetleri görüyor.

Lidl, Hershey ve Revlon'un üçünün de planı vardı. Eksik olan aktif kontroldü: dürüst takip, erken eskalasyon ve uyarı işaretleri ortaya çıktığında gerçek bir tepki.

Uzun bir SAP programında kapsam kaymasını nasıl yönetirim?

Her kapsam değişikliğine onaydan önce yazılı bir etki değerlendirmesi verin: zaman, maliyet ve kaynaklar. Onsuz, bir değişikliği onaylamak bilinmeyen bir şeyi onaylamak demektir.

En etkili kural: her ekleme başka bir şeyin yerini almalı. Bu tek kısıt, iş liderlerini dürüstçe önceliklendirmeye zorlar.

Yöneticiler bunu desteklemeli. Bir CFO ya da COO değişiklik kontrolünü açıkça desteklediğinde, gayriresmî talepler hızla azalır. RISE ve GROW programlarında, her boşluk için uzantı kararı bunun üzerine teknik bir kontrol ekler.

İş kırılım yapısı nedir ve SAP için neden önemlidir?

WBS, toplam kapsamı her biri bir sahibi ve teslim tarihi olan teslimatlara böler. Bir SAP programında bu, süreç tasarımı, yapılandırma, veri geçişi, entegrasyon, test, eğitim ve cutover demektir; hepsi görevlere kadar kırılır.

Pratik değeri bağımlılık haritalamasıdır. Veri geçişi entegrasyon testini, o UAT'yi, o da cutover'ı besler. Biri kaydığında, aşağı akıştaki etki hemen görünür.

RISE with SAP, proje planlama ve kontrolünü nasıl değiştirir?

SAP, teslimatın bir katılımcısı olur. Altyapıyı ve teknik operasyonları yürütür ve müşteri başarı ekibi benimseme ve değer üzerine kendi ritmini işletir.

Üç değişiklik gelir. Platform sorunları için, iş ortağından geçmeyen, SAP'ye belgelenmiş bir eskalasyon yoluna ihtiyacınız var. Clean core altında her boşluğun nasıl ele alınacağına karar vermek için yönlendirme komitesinin altında bir uzantı gözden geçirme forumuna ihtiyacınız var. Ve SAP'nin müşteri başarı ritmini paralel yürütmek yerine yönetişiminize katmalısınız.

Bir SAP programında yönlendirme komitesi ne yapmalı?

Karar vermeli. İşi, program ekibinin çözemediklerini çözmektir: kaynak çatışmaları, kapsam anlaşmazlıkları, bütçe değişiklikleri ve fonksiyonlar arası yetki gerektiren her şey. Karar çıkmadan biten bir yönlendirme toplantısı, bir durum güncellemesiydi.

Büyük bir programda aylık yönlendirme, sorunları dört haftaya kadar bekletir. Aktif teslimatta asgari iki haftada bir, cutover ve hypercare'de haftalık. İlerleme raporlarını önceden gönderin ve toplantıyı onların ortaya çıkardığı kararlar için kullanın.