SAP uygulamasında kapsam kayması nasıl önlenir

SAP uygulamasında kapsam kaymasını, her değişikliği görünür ve onaylaması pahalı hale getirerek önlersiniz. Kapsam dışında kalanı, kapsam içindekiler kadar özenle yazın. Her talebi zaman, maliyet ve kalite üzerinde etki değerlendirmesiyle birlikte değişiklik kontrolünden geçirin. Her ek için bir takas isteyin. Üst yönetim desteğiyle bir kapsam dondurma tarihi belirleyin ve aynı disiplini sistem entegratörü (SI) sözleşmesine de uygulayın. Bu rehber, S/4HANA programlarındaki program direktörleri, sponsorlar ve PMO'lar için. Aşağıdaki değişiklik maliyeti tablosunu ve sözleşme maddelerini bir sonraki yönlendirme komitesi sunumunuzda kullanın.

SAP projelerinin çoğu bütçeyi ve teslim tarihlerini aşıyor, bunun en yaygın nedeni de kapsam kayması. SAP projeleri kontrolden çıkan onlarca kurumla çalıştım ve aşım yönlendirme raporuna yansımadan önce üç sinyal ortaya çıkıyor. Küçük değişiklikler etki değerlendirmesi yapılmadan birikiyor. Değişiklik kontrolü, belgelenmiş yetki yerine kişisel ilişkilerle yürüyor. Sponsor da proje ekibinin bir hafta sonra duyduğu şeyleri kahve eşliğinde onaylıyor.

Bir ilaç şirketi müşterim net bir 18 aylık takvimle başladı. Üç yıl sonra hâlâ uygulama yapıyordu ve maliyetler iki katına çıkmıştı. Bir üretim şirketinin CIO'su, gereksinimler sürekli değiştiği için ekibinin aylarca yapılandırdığı modüllerin tamamını çöpe attığını söyledi. Kapsam o kadar büyümüştü ki kimse özgün planı tanımıyordu.

Bunlar istisnai durumlar değil. SAP programlarının başarısız olmasının en yaygın yolu bunlar.

Masum başlar. Bir iş lideri “sadece küçük bir değişiklik” ister. Sonra bir tane daha. “Madem içindeyiz, şunu da...” cümlesi, hiçbir teknik zorluğun yapamadığı kadar çok SAP uygulamasını raydan çıkardı.

Temiz başladığımız bir perakende müşterisiyle çalıştım: çekirdek Finans ve temel Malzeme Yönetimi. Altı ay sonra CMO müşteri analitiği istedi. Sonra COO gelişmiş depo fonksiyonlarına ihtiyaç duydu. Özgün dokuz aylık takvim tehdit altındaydı. Geri ittim ve iki talebi de reddettim. Bu disiplin işin kendisi.

Her değişiklik kapsam kayması değildir. Bazen kimsenin öngörmediği kritik tasarım boşlukları bulursunuz. Bazen düzenlemeler proje ortasında değişir. Bunlar meşrudur ve takvim ile bütçe düzeltmeleriyle birlikte bir süreçten geçer. Kapsam kayması ise kendiliğinden belirir, genellikle koridordaki bir sohbetten sonra.

Bir üretim müşterisi 10 özel raporla başladı ve 47 ile bitirdi; her biri tasarım, geliştirme ve test süresi ekledi. Yalnızca raporlama iş akışı bütçeyi %200 aştı.

%200

kapsam kayması özel raporları 10'dan 47'ye çıkardıktan sonra raporlama iş akışının bütçe aşımı

Kaynak: Üretim müşterisi programı

Uyarı işaretleri

İzlediğim işaretler ve her birine verdiğim yanıt şunlar:

Uyarı işareti	Altta yatan neden	Yanıt
“Bir şey daha” günlük dil haline geliyor	Belirsiz kapsam sınırları	İş liderleriyle temel planı yeniden oluşturun; resmî değişiklik kontrolünü uygulayın
İş liderleri özellikleri gayriresmî olarak ekliyor	Aşağı akış etkisinin anlaşılmaması	Her talebi etki değerlendirmesinden geçirin; maliyeti gösterin
Takvim resmî bir yeniden planlama olmadan uzuyor	Sessiz kapsam genişlemesi	Kapsam kontrol noktaları koyun; değişiklik kurulunun onayıyla yeniden planlayın
Dokümantasyon geliştirilenle artık örtüşmüyor	Gayriresmî kapsam yönetimi, sürüm kontrolü yok	Onaylanan her değişiklikle spesifikasyonları ve planları güncelleyin
Bütçe harcaması ilerlemenin önüne geçiyor	Belgelenmemiş değişikliklerden gelen gizli efor	Eforu iş paketlerine karşı izleyin; sapmaları inceleyin
Ekip yetişmek için gece ve hafta sonu çalışıyor	Kapsam kapasiteyi aşıyor	Değişiklik kuruluna eskale edin; kapsam kararını zorlayın
İş, BT ve iş ortağı arasında suçlama	Kapsam zaten kontrolden çıkmış	Kapsamı dondurun, kök neden incelemesi yapın, temel planı sıfırlayın

Her şey birbirine bağlı

SAP her şeyi birbirine bağlar. Finans tedarik zincirini etkiler. İK bordroya dokunur. Satış stokla bağlantılı. Bir değişiklik on şeyi bozabilir.

Bir müşteri satın alma siparişi sürecine tek bir alan ekledi. Önemsiz görünüyordu. Üç arayüzü bozdu ve departmanlar genelinde rapor yeniden yazımı gerektirdi. Başka bir müşteri fiyatlandırma prosedüründe “küçücük bir değişiklik” istedi; bunun için tüm fiyatlandırma yapısının yeniden yapılandırılması gerekti: küçücük bir değişiklik için üç haftalık iş ve 40.000 dolar danışmanlık ücreti.

On yılda bir yaşanan baskı

Şirketlerin çoğu SAP'yi 10 ila 15 yılda bir uygular. Her departman, on yıl boyunca başka bir şansı olmayacağını bilir. Kimse “2. faz” lafını duymak istemez; çoğu kurumda bunun anlamı hiçbir zaman gelmeyecek demektir. Bu yüzden her şey mevcut projeye itilir ve kapsam listesi bir dilek listesine dönüşür.

Clean Core neyi değiştirir

Clean Core, özelleştirmeye teknik bir fren koyar. S/4HANA Cloud Public Edition'da çekirdeği değiştirmek mümkün değildir: uzantılar yayımlanmış API'ler üzerinden, SAP BTP'de on-stack ya da side-by-side olarak geçer. Private Edition'da ve on-premise'ta değişiklik hâlâ mümkündür, ancak SAP'nin yönlendirmesi bunu son çare olarak görür, çünkü her biri yükseltme işi ekler.

Faydalı yan etki kapsam disiplinidir. “Standart siparişten tahsilata sürecine şu onay adımını ekleyelim” talebi, gelişigüzel bir yapılandırma sohbeti olmaktan çıkar ve kendi tasarım, geliştirme ve test maliyeti olan bir uzantıya dönüşür. Yönlendirme komitesinin altına, onaylama ya da reddetme yetkisi olan bir mimarın bulunduğu bir uzantı inceleme forumu koyun; bu taleplerin çoğu temel plana girmeden durur. Bu forumu olmayan on-premise programlar eski kalıplara geri düşer. Clean Core rehberim bir tanesinin nasıl kurulacağını açıklıyor.

1. Kapsamı açık kapsam dışı maddelerle tanımlayın. Kapsam dışında olanı, kapsam içindekiler kadar özenle belgeleyin ve ikisi için de imza alın. Tartışmalar belirsizlikten çıkar.
2. Sonuçları olan resmî değişiklik kontrolü yürütün. Her değişiklik, onaylayan kişinin görebileceği biçimde maliyet, zaman ve kalite üzerinde bir etki değerlendirmesi gerektirir.
3. Kapsam sınırlarını her yönlendirme toplantısında iletin. Kapsam durumunu basit bir kırmızı, sarı, yeşil görünümle gösterin. Kaymanın büyük kısmı yanlış anlamadır.
4. Bir kapsam yönetim planı yazın. Değişikliklerin nasıl değerlendirileceğini, onaylanacağını, eskale edileceğini ve izleneceğini ortaya koyun; böylece her iş akışı bunları aynı şekilde ele alır. SAP proje kapsamı şablonum bir başlangıç yapısı sunuyor.
5. MoSCoW ile önceliklendirin. Must have, Should have, Could have, Won't have (bu sefer yok). Must have listesini kısa tutmak için sıkı durun.
6. Her kararı sürüm kontrolüne alın. Onaylanan her değişiklik temel planı günceller. Reddedilen her değişiklik gerekçesiyle kaydedilir.
7. Takas isteyin. Yeni bir gereksinim gelirse, başka bir şey çıkar. Bir bedeli olduğunda olmazsa olmazlar hızla isteğe bağlı hale gelir.

Bunların kalıcı olmasını sağlayan, kullandığım üç teknik var.

İmza disiplini. İş liderlerine onaylanan gereksinimleri imzalatın. Bir programda bir iş lideri belirli bir süreç akışını hiç onaylamadığına yemin etti. İmzasını taşıyan belgeyi çıkardık ve tartışma bitti. İmza bürokrasi değil. Aynı tartışmanın altı ay sonra yeniden başlamasını engeller.

Dalga etkilerini gösterin. Bir müşteri için, bir satış siparişindeki tek bir alanı değiştirmenin raporlamadan arayüzlere ve güvenlik rollerine kadar 14 alanı nasıl etkileyeceğini gösteren bir demo hazırladım. Davranış değişti. Eğitimin maliyeti saatlerdir. Dalga etkilerini anlamamanın maliyeti aylardır.

Değişikliğin maliyetini gösterin. Tasarım sırasında bir değişiklik 5.000 dolara mal olabilir. Aynı değişiklik test sırasında 50.000 dolara mal olabilir. İnsanların önüne bunun basit bir grafiğini koyun, gelişigüzel talepler yavaşlar.

Bunlar, ABD pazarındaki S/4HANA programları için gösterge niteliğinde değişiklik maliyeti aralıkları. Karmaşıklığa ve iş ortağına göre değişir. Bunları teklif olarak değil, referans noktası olarak kullanın.

Faz	Küçük bir değişikliğin tipik maliyeti	Orta bir değişikliğin tipik maliyeti
Explore (tasarım)	2 bin ile 10 bin dolar	10 bin ile 30 bin dolar
Erken Realize	5 bin ile 20 bin dolar	20 bin ile 80 bin dolar
Realize ortası (geliştirme)	15 bin ile 50 bin dolar	50 bin ile 200 bin dolar
Geç Realize (test)	30 bin ile 100 bin dolar	100 bin ile 400 bin dolar
Deploy ve cutover	80 bin ile 300 bin dolar	300 bin ile 1 milyon dolar ve üzeri
Hypercare (canlıya geçişten sonra)	150 bin ile 500 bin dolar	500 bin ile 2 milyon dolar ve üzeri

Bu örüntü, araştırmaların onlarca yıldır bulduğuyla örtüşüyor. NASA'nın hata maliyetinin artışı üzerine bir çalışması, entegrasyon ve testte yakalanan bir gereksinim hatasının düzeltilmesinin, gereksinim aşamasında yakalananın 21 ila 78 katına mal olduğunu, sistem işletime girdikten sonra ise çok daha fazlasına mal olduğunu buldu. Kapsam yönetişimi, değişiklikleri o eğrinin ucuz tarafında tutmak için vardır.

Önemli olan sözleşme maddeleri

Belirsiz sözleşmeler pahalı sorunlar yaratır. Yalnızca “S/4HANA'yı uygulayın” yazan bir sözleşme imzalayan bir müşteri gördüm. İş ortağı daha sonra belirli süreçlerin ek ücret gerektiren eklentiler olduğunu iddia etti ve müşteri iki katını ödedi. Şu maddeler bunu önler:

Madde	Amaç
Açık kapsam dışı maddeleri olan kapsam	Sabit fiyatın neyi kapsadığını sınırlar ve eklentiler konusundaki belirsizliği kaldırır
Yaygın değişiklikler için önceden anlaşılmış oranlar	Baskı gelmeden önce raporlar, arayüzler ve yapılandırma değişiklikleri için fiyatları sabitler
Danışman sürekliliği	Yeni danışmanların çözülmüş kararları yeniden açıp kapsamı genişletmesini engeller
Her iki tarafta onay yetkisi	Kıdemsiz danışmanların kimsenin yetkilendirmediği özellikleri vaat etmesini engeller
Kilometre taşına dayalı faturalandırma	Ödemeyi geçen süreye değil, imzalanmış teslimatlara bağlar
Teslimat başına kabul kriterleri	Kimse tartışmaya başlamadan önce “bitti”nin ne olduğunu tanımlar
Clean Core uzantı maddesi	Uzantıların yayımlanmış API'leri ya da SAP BTP'yi kullanmasını şart koşar; ilk büyük yükseltmede yeniden işi önler

ERP sözleşme müzakeresi notlarım, bu maddeleri nasıl kabul ettireceğinizi anlatıyor.

Değişiklik kontrol kurulu

Doğru kişiler olduğunda bir değişiklik kurulu işe yarar. Benimkini üç rolle kurarım: fonksiyonu önemseyen bir iş karar vericisi, takvimi önemseyen bir proje yöneticisi ve bütçeyi önemseyen bir finans lideri. Bu denge, hiçbir önceliğin diğerlerine baskın çıkmasını önler.

1. 01Talep oluşturulurYazılı olarak, kahve eşliğinde değil
2. 02Etki değerlendirmesiZaman, maliyet ve kalite, kimse onaylamadan önce
3. 03Takas belirlenirYer açmak için başka bir şey çıkar
4. 04Değişiklik kurulu karar verirMasada iş, proje ve finans var
5. 05Temel plan güncellenirReddedilen değişiklikler gerekçesiyle kaydedilir

Kapsam yalnızca kurul üzerinden hareket eder

Kurulun gerçek bir yetkisi olmalı. Bir programda hiçbir kapsam değişikliği kurulun onayı olmadan gerçekleşmedi. Tek bir tane bile. Koridor anlaşmaları durdu. Satış başkan yardımcısı yeni gereksinimleri araya sokmaya çalıştığında, ekibin işaret edebileceği belgelenmiş bir onay matrisi vardı.

Kararların çoğu kurul düzeyinde kalmalı. Yalnızca gerçek anlaşmazlıklar sponsora gider; bu da sponsoru boğmadan ilgili tutar. İş akışı liderleriyle iki haftada bir kapsam incelemesi yapın ve gönderilen, onaylanan ve reddedilen talepleri raporlayın. İnsanlar bir durum raporunda “bu ay %15 kapsam büyümesi” gördüğünde davranış değişir.

Bazı değişiklikler gereklidir. Bir ilaç müşterim, uygulamanın ortasında yeni FDA düzenlemelerine yakalandı. Bunların girmesi gerekiyordu. Bu kapsam kayması değil. Bu gerçeğin ta kendisi.

Meşru bir değişiklik geldiğinde iki soru sorun. İşe yarayacak en küçük çözüm nedir? Ve talep eden kişiye: yer açmak için neyi çıkarmaya razısınız? Bir talebin bedeli olduğunda aciliyet hızla düşer.

Seçenekler takvimi uzatmak, bütçe eklemek, diğer gereksinimleri kesmek, kişi eklemek ya da bunların bir karışımı. Hangisini seçerseniz seçin belgeleyin ve tüm temel plan belgelerini aynı anda güncelleyin. Eskimiş belgeler bir sonraki kapsam sorunları turunu yaratır.

Yapay zeka artık evrak işlerinde yardımcı oluyor. Microsoft Copilot gibi asistanlar uzun değişiklik talebi yazışmalarını kurul için karar vermeye hazır bir özete dönüştürüyor, SAP Cloud ALM de gereksinimleri, değişiklikleri ve testleri birbirine bağlı tutarak bir değişikliğin etkisinin izlenmesini kolaylaştırıyor. Yapay zeka bir değişikliğin 14 alana dokunduğunu gösterebilir. COO'ya, talebinin CFO'nun talebinin gerçekleşmeyeceği anlamına geldiğini söyleyemez. O konuşma hâlâ sizin.

Birlikte çalıştığım bir üretim şirketi SAP projesini zamanında bitirdi; bu olması gerekenden daha nadir. Kapsam dondurma tarihini erken belirledi ve bundan sonraki her değişiklik CEO'nun kişisel onayını gerektiriyordu. Proje bütçe artığıyla kapandı ve canlıya geçişte kimse hafta sonu çalışmıyordu.

Başka bir müşteri jeton sistemi kullandı: her departman tüm proje için üç değişiklik jetonu aldı. Bir değişiklik mi istiyorsunuz? Bir jeton harcayın. İnsanlar neyin önemli olduğunu iyice düşündü ve “olmazsa olmazlar” sınırlı bir para birimine mal olduklarında yeniden değerlendirildi.

İki yaklaşım da karmaşık değil. İkisi de disiplin ve liderlik desteği gerektirir. Herhangi bir kapsam sürecinin sınavı, COO'nun proje odasına “sadece küçük bir değişiklik” diyerek girdiği gündür. Süreci o gün için kurun.

SAP projesinde kapsam kayması nedir?

Zaman çizelgesi, bütçe ya da kaynaklarda karşılık gelen değişiklikler olmadan gereksinimlerin kademeli ve kontrolsüz büyümesi. SAP'de genellikle küçük eklemelerle başlar: ekstra raporlar, ekstra alanlar, “sadece küçük bir iş akışı değişikliği”. Her biri zararsız görünür. Birlikte aylar ekler.

Meşru kapsam değişiklikleri bir süreçten geçer ve takvim ile bütçe düzeltmeleriyle birlikte gelir. Kapsam kayması ise gayriresmî biçimde gelir ve değişiklik kontrolünü atlar.

SAP projelerinde kapsam kaymasının en yaygın nedenleri nelerdir?

Üçü sürekli karşımıza çıkıyor: belirsiz başlangıç gereksinimleri, dolayısıyla her şey kapsam içindeymiş gibi savunulabiliyor; resmî değişiklik kontrolünün olmaması, dolayısıyla değişiklikler her düzeyde içeri sızıyor; ve “on yılda bir” zihniyeti, yani her departmanın yıllardır biriken sorunları bu projede çözmeye çalışması.

SAP'nin iç içeliği üçünü de güçlendiriyor. Bir değişiklik birbirine bağlı on süreci bozabilir ve iş liderleri bu bağlantıları göremezse, etki test sırasında, maliyeti kat kat daha yüksekken ortaya çıkar.

Clean Core kapsam kayması riskini nasıl değiştirir?

Teknik bir fren ekler. S/4HANA Cloud Public Edition'da çekirdek değiştirilemez, bu yüzden her boşluk kendi tasarım, geliştirme ve test maliyeti olan bir uzantıya dönüşür. Private Edition'da ve on-premise'ta değişiklik mümkündür ama yükseltme işi ekler; bu yüzden SAP'nin yönlendirmesi bunu önermez.

Karar yetkisi olan bir mimarın bulunduğu bir uzantı inceleme forumu, birçok talebi temel plana girmeden durdurur. Bu forum olmadan on-premise programlar eski alışkanlıklara geri kayar.

Kapsam kayması ile gold-plating arasındaki fark nedir?

Kapsam kayması iş tarafından gelir: üzerinde anlaşılanın ötesindeki talepler. Gold-plating teslimat ekibinden gelir: kimsenin istemediği karmaşıklık.

SAP terimleriyle gold-plating, basit yönlendirmenin yeteceği yerde bir danışmanın ayrıntılı iş akışı mantığı kurmasıdır. Kapsam kayması ise temel MM için kapsamlanmış bir projenin altıncı ayında COO'nun gelişmiş depo fonksiyonları istemesidir. İkisi de maliyeti ve süreyi şişirir ve ikisi de aynı disiplini gerektirir.

Gerçekten işe yarayan bir değişiklik kontrol süreci nasıl yapılandırılır?

Üç unsur. Her talep, zaman çizelgesi, bütçe ve kaynaklar üzerinde bir etki değerlendirmesi taşır. Onay kurulunda bu üçünün her birini önemseyen biri bulunur; her şeyi onaylayacak olan yalnızca iş liderleri değil. Ve her ek bir takas gerektirir: başka bir şey çıkar.

Yalnızca bu son kural, gerçekten kritik olmayan talepleri eler.

Kapsam kaymasından tamamen kaçınabilir misiniz?

Hayır. Birkaç aydan uzun süren herhangi bir programda iş koşulları kayar, düzenlemeler değişir ve tasarım boşlukları ortaya çıkarır.

Amaç ortadan kaldırmak değil, kontrol etmektir. Kontrollü değişiklik belgelenmiş bir sürece uyar, etkisi değerlendirilir ve temel planı günceller. Kontrolsüz değişiklik süreci atlar ve testte ya da canlıya geçişten sonra, kimsenin planlamadığı bir maliyet olarak ortaya çıkar.

Uzun bir SAP programında kapsam dondurmayı yönetmenin en iyi yolu nedir?

Ona bir sonuç ve görünür üst yönetim desteği verin. Kullandığım en etkili sürüm şuydu: dondurma tarihi ilk günden proje başlatma belgesinde yer alır, değişiklik süreci “dondurma”nın pratikte ne anlama geldiğini tanımlar ve sponsor tarih gelmeden önce yönlendirme toplantısında bunu herkesin önünde pekiştirir.

CEO dondurmadan sonraki her değişikliği bizzat onaylamak zorunda kaldığında, liste çok kısa kalır.