
İçindekiler
- Onaylayacak kişiler için yazın
- Kararı yönetici özeti verir
- Üç okuyucu için yazın
- SAP iş gerekçesi şablonu
- Finansal gerekçe
- Bir finans direktörünün arayacağı maliyetler
- CFO'nun inanacağı ROI, geri ödeme ve faydalar
- RISE, GROW ve yapay zeka iş gerekçesinde neyi değiştirir
- İş gerekçelerini öldüren hatalar
- Sık sorulan sorular
Karar vericiler sorunu, maliyeti, getiriyi ve riski tek sayfada, kendi dillerinde görebildiklerinde bir SAP iş gerekçesi onay alır. Aşağıdaki yedi bölümlü yapıyı kullanın, en az beş yıllık tüm maliyetleri ekleyin, fayda varsayımlarını temkinli tutun ve CFO, BT ve iş birimi için ayrı bölümler yazın. Takılan iş gerekçelerinin çoğu fikirde değil, sunumda başarısız olur.
Fikir sağlam olduğu halde onayların haftalarca, bazen aylarca sürdüğünü gördüm. İlk sunumun başarısız olduğu bir S/4HANA geçişini hatırlıyorum. Teklif sistem mimarisi diyagramlarıyla doluydu, operasyonel kazanımlar hakkında neredeyse hiçbir şey yoktu. Açılışı sevkiyat gecikmelerini kısaltmaya, envanter maliyetlerini düşürmeye ve ekibin bunu nasıl teslim edeceğine odaklayacak şekilde yeniden kurguladık. CFO tek toplantıda onayladı.
Şablondan önce bir nokta daha. Uygulama ortağınız iş gerekçenizi yazmamalı. Onun teşviki programı başlatmak. Sizinki bitirmek. 40 milyon dolarlık programlar böyle sessizce 90 milyon dolarlık programlara dönüşür.
Kararı yönetici özeti verir
Tek sayfada tutun. Yöneticiler başka hiçbir şey okumayabilir.
Sorunla başlayın, rakamlarla. Teklifi teknik ayrıntı olmadan bir iki cümleyle ifade edin. Ardından ana faydaları rakamlarla, sade bir takvimi, toplam yatırımı ve önemli riskleri azaltma yollarıyla birlikte verin.
Daha önce desteklediğim şirketlerden birinde özet “teknik nesneler” ve “Embedded HANA” gibi terimlerle açılıyordu. CFO ilk paragraftan sonra belgeyi bıraktı. Özeti, “envanter azaltımıyla yıllık 2,5 milyon dolar maliyet tasarrufu” ve “%40 daha hızlı sipariş işleme” ile başlayacak şekilde yeniden yazdık. Aynı CFO sayfanın tamamını okudu ve projeyi o hafta onayladı.
Özet bitince projenin dışından birine verin. Size geri anlatabiliyorsa işe yarıyordur.
Üç okuyucu için yazın
Herkese tek bir sürüm işe yaramaz. Güçlü tekliflerin yanlış kitle için yazıldığı için öldüğünü izledim.
CFO ve yönetim kurulu, notlara bakmadan tekrar edebilecekleri rakamlar ister: “Yıllık 2 milyon dolar tasarruf, 18 ay geri ödeme.” Risklerin açıkça yazılmasını isterler. Bu kitlede açık sözlülük iyimserliği yener.
BT, entegrasyon kapsamının mevcut sistemlere karşı eşlenmiş halini, canlıya geçiş sonrası destek modelini ve benzer projelerin nerede yanlış gittiğini bildiğinizin kanıtını ister.
İş kullanıcıları, haftalarının önce ve sonra görev görev resmini ve eğitim süresi için dürüst bir rakam ister. Haftada binlerce kez tekrarlanan küçük bir fazladan tıklama gerçek bir soruna dönüşür.
Bir keresinde bir CFO, sorularının hiçbirini yanıtlamadığı için bir iş gerekçesini toplantının ortasında reddetti. Onu her kitle için bir tane olmak üzere üç bölüm halinde yeniden kurduk ve her birini ölçülebilir KPI'lara bağladık. Teknik plan hiç değişmedi. Yalnızca anlatış biçimi değişti.
Kullandığım yedi bölüm bunlar, bu sırayla. CFO'su maliyet ayrıntılarını 23. sayfaya gömülü bulan, CIO'su ise teknik riskleri hiç bulamayan bir üretim şirketini hatırlıyorum. Onay altı ay kaydı. Yapılandırılmış bir sürümle onay iki hafta sürdü, içerik ise neredeyse hiç değişmemişti.
| Bölüm | İçermesi gerekenler |
|---|---|
| Yönetici özeti | Rakamlarla sorun, teklif, faydalar, toplam yatırım, takvim, başlıca riskler |
| Mevcut durum | Acı noktaları, bugünkü maliyetleri ve hiçbir şey yapmamanın maliyeti |
| Önerilen yaklaşım | Kapsam, modüller, dağıtım modeli (RISE, GROW veya on-premise), ana entegrasyonlar |
| Finansal gerekçe | Beş yıllık maliyet ve faydalar, ROI, geri ödeme, büyük programlar için NPV |
| Uygulama planı | Fazlar, kilometre taşları, ekip, bağımlılıklar |
| Riskler | Sahipleri ve azaltma yollarıyla somut riskler |
| Yönetişim | Sponsor, yönlendirme komitesi, değişiklik kontrolü, kapsam genişletme onay kuralları |
Mimari diyagramlarını ve yapılandırma ayrıntılarını ek bölümde tutun.
Bir finans direktörünün arayacağı maliyetler
Eksik maliyetler, zayıf faydalardan daha fazla iş gerekçesini öldürür. Bunların hepsini ekleyin:
- Yazılım: on-premise için lisans artı yıllık destek, RISE ve GROW için abonelik.
- Uygulama ortağı ücretleri.
- Altyapı, kendiniz işletiyorsanız; RISE kapsamında SAP bunu abonelik içinde işletir.
- İç ekip emeği. En sık eksik bırakılan kalem budur.
- Eğitim ve değişim yönetimi.
- Veri taşıma ve temizleme.
- Yinelenen destek. On-premise SAP Enterprise Support uzun süredir yıllık lisans değerinin yaklaşık %22'si düzeyinde. RISE ve GROW için sözleşme süresinin her yılının abonelik bedelini gösterin.
- Canlıya geçiş sonrası hypercare.
Yedinci madde, birçok finans direktörünün ilk baktığı yerdir. İkinci yıldan beşinci yıla kadarki rakamlar eksikse güvenilirlik anında düşer. SAP uygulama maliyeti rehberimde her kalem için tipik aralıklar var; CFO'lar için sözleşme inceleme rehberim ise ortak tarafını ele alıyor.
CFO'nun inanacağı ROI, geri ödeme ve faydalar
ROI, net faydanın toplam yatırıma bölünmesidir. 2 milyon dolarlık maliyete karşı beş yıllık 3,5 milyon dolar fayda, 1,5 milyon dolarlık net fayda, yani %75 demektir.
Geri ödeme süresi, yatırımın yıllık net nakit faydaya bölünmesidir. Yılda 400.000 dolar getiren 1,2 milyon dolarlık bir proje üç yılda kendini öder.
NPV, gelecekteki nakit akışlarını bugünkü değere indirger. Yönetim kurulu isterse finans ekibinizi odaya çağırın.
Faydaları hesabı göstererek nicelleştirin:
- Envanter: %20 elde tutma maliyetiyle 10 milyon dolarlık stok %15 azaltılırsa yılda 300.000 dolar tasarruf edilir.
- Süreç süresi: günde 200 kez yapılan 45 dakikalık bir görev 15 dakikaya indirilirse, saat başı 30 dolarla, 250 iş günü boyunca yılda yaklaşık 750.000 dolar tasarruf edilir.
Kademeli bir artış gösterin. Canlıya geçişten sonraki ilk yılın faydaları genellikle oturmuş düzene göre daha düşüktür. Nicelleştiremediğiniz faydaları ayrı bir listede tutun, böylece nicelleştirebildiklerinizi sulandırmazlar.
Temkinli olun. Zor SAP projeleri için, maliyetler konusunda acımasızca dürüst, faydalar konusunda temkinli olarak onay alan işletmeler gördüm. Bir üretim müşterisi S/4HANA projesi için önce %30 ROI gösterdi. Sorgulandığında gerekçeyi daha gerçekçi bir %18'e çekti. CFO bu açık sözlülüğü takdir etti ve onayladı.
Teknik plan hiç değişmedi. Yalnızca anlatış biçimi değişti.
Abonelik, lisansın ve desteğin yerini alır. RISE ve GROW abonelik olduğundan birinci yıl, on-premise lisans satın almaktan daha ucuzdur. Beş yıllık toplam kullanıcı sayısına, kapsama ve sözleşme süresine bağlıdır. Birinci, üçüncü ve beşinci yılı yan yana gösterin.
Değişen yalnızca nakit değil, muhasebedir. IFRS kapsamında bir bulut sözleşmesi çoğu zaman size kontrol ettiğiniz bir yazılım varlığı değil, yazılıma erişim hakkı verir. Bu durumda IFRS Yorumlar Komitesi'nin 2021 gündem kararı, yapılandırma ve özelleştirme maliyetlerinin genellikle hizmetler alındıkça gider yazılacağı, aktifleştirilmeyeceği anlamına gelir. Bu, program maliyetinin büyük bir bölümünü bilançodan gelir tablosuna taşıyabilir. RISE veya GROW sözleşmenizin muhasebe işlemini, finansal gerekçe yönetim kuruluna gitmeden önce denetçilerinizle netleştirin.
Clean Core, uzun vadeli maliyeti değiştirir. Yayımlanmış arayüzler üzerine kurulan uzantıların tasarımı daha pahalıdır ama yükseltmelerde ayakta kalırlar. Değişiklikler bugün daha ucuzdur, sonraki her yükseltmede pahalıdır. Beş yıllık bir model bu farkı göstermelidir, özellikle çekirdeğin hâlâ değiştirilebildiği Private Edition'da.
Yapay zeka, iş gerekçesine ancak iş akışı düzeyindeki varsayımlarla girer. Joule ve diğer yapay zeka özellikleri belirli görevlerde zaman kazandırabilir. Her yapay zeka faydasını adı konmuş bir iş akışına, bir kullanıcı sayısına ve savunabileceğiniz bir benimseme oranına bağlayın. CFO'lar her hafta “yapay zeka işi dönüştürecek” sunumları görür ve bunlara büyük iskonto uygular.
Hiçbir şey yapmamanın maliyetini dışarıda bırakmak. Mevcut sistem yılda 500.000 dolarlık yeniden işe yol açıyorsa, bu iş gerekçesinde yer almalı. Bazen SAP yatırımından büyüktür.
Aksaklığı yok saymak. Eğitim süresi, cutover kesintisi ve canlıya geçişten sonraki yavaş ilk ay getiriyi düşürür.
Muğlak riskler. “Veri sorunları” bir risk değildir. “İlk 30 günde fatura reddine yol açan ana veri uyumsuzluğu” risktir.
Ayrıntısız tek bir canlıya geçiş tarihi. Gecikmeler genellikle devir tesliminde başlar: gereksinimlerden yapılandırmaya, testten onaya, eğitimden hazırlığa. Bunları gösterin.
Şirketin büyüklüğünü göz ardı etmek. Çalıştığım bir projede küçük bir distribütör, büyük bir kurumun yönetişim sürecini kopyaladı. Haftalık yönlendirme toplantıları, süreç sadeleştirilene kadar saatlerce kaybedilen verimliliğe dönüştü. 200 çalışandan küçük şirketler için 8 ila 10 sayfa yeterlidir. Büyük kuruluşlar eksiksiz finansal modelleme ve ayrıntılı bir yönetişim bölümü bekler.
Onay almak için altı ay harcayan bir üretim ekibiyle çalıştım. İş gerekçesini dört kez revize ettiler, çünkü her sürüm farklı bir onaylayana yanıt veriyor, diğerlerini görmezden geliyordu. Baştan üç okuyucu için birden yazmak, bu sürenin çoğunu kazandıracaktı. Onay alındıktan sonraki belge proje başlatma belgesidir.
Bir SAP iş gerekçesi neleri içermelidir?
Yedi bölüm: yönetici özeti, mevcut durum ve hiçbir şey yapmamanın maliyeti, önerilen yaklaşım ve dağıtım modeli, ROI ve geri ödeme içeren beş yıllık finansal gerekçe, uygulama planı, sahipleriyle somut riskler ve bir yönetişim modeli. Teknik ayrıntıyı ek bölümde tutun.
SAP iş gerekçeleri neden reddedilir?
Genellikle faydalar muğlak ya da maliyetler eksik olduğu için, özellikle yinelenen destek veya sonraki abonelik yılları. Diğer yaygın nedenler: üstü kapatılan riskler ya da finans, BT ve operasyonun hepsinin ikna edilmesi gerekirken tek bir kitle için yazılmış bir belge.
Bir SAP uygulaması için ROI nasıl hesaplanır?
Dönem boyunca, genellikle beş yıl, elde edilen net faydayı toplam yatırıma bölün. Her maliyeti ekleyin: yazılım veya abonelik, ortak ücretleri, iç ekip emeği, eğitim, veri taşıma, yinelenen destek ve hypercare. Canlıya geçişten sonra kademeli artışla temkinli faydalar kullanın. Gerçekçi bir %18, iyimser bir %35'ten daha hızlı kapanır.
RISE with SAP iş gerekçesini nasıl değiştirir?
Abonelik, lisansın ve yıllık desteğin yerini alır; dolayısıyla iş gerekçesinde sözleşme süresinin her yılı için bir maliyet görünümü gerekir. Altyapıyı SAP işletir, bu da donanım harcamasını ortadan kaldırır. IFRS kapsamında bir bulut hizmetinin yapılandırma maliyetleri genellikle aktifleştirilmez, gider yazılır; bu yüzden muhasebe işlemini denetçilerinizle erkenden netleştirin.
Bir SAP iş gerekçesi ne kadar uzun olmalı?
Tek sayfalık bir yönetici özeti, ardından orta ölçekli bir program için kabaca 15 ila 25 sayfa, büyük bir kuruluş için en fazla 40 sayfa. Daha uzun olan her şeyi eklere koyun. Sponsorun bundan bilgi vermek için bir saate ihtiyacı varsa, çok uzundur.
SAP iş gerekçesinde hiçbir şey yapmamanın maliyeti nedir?
İşletmenin mevcut sistemde kalarak kaybetmeye devam ettiği şey: elle yapılan geçici çözümler, mutabakat eforu, raporlama gecikmeleri, eskiyen sistemlerin desteği ve güvenilmez veriye dayanan kararlar. ECC'deyseniz, 2027 sonrasındaki uzatılmış bakımın maliyetini de ekleyin.
Sonraki adım
Şu anda bir ERP programı mı yürütüyorsunuz?
Bu makale şu anda içinde olduğunuz bir programa dokunduysa, 30 dakikalık bir görüşme genellikle bir hafta daha süren iç analizden daha fazla yol aldırır.




